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Author's Abstract 



The temporal logic of actions (TLA) is a logic for specifying and reasoning 
about concurrent systems. Systems and their properties are represented in 
the same logic, so the assertion that a system meets its specification and the 
assertion that one system implements another are both expressed by logical 
implication. TLA is very simple; its syntax and complete formal semantics 
are summarized in a little over a page. Yet, TLA is not just a logician's 
toy; it is extremely powerful, both in principle and in practice. This report 
introduces TLA and describes how it is used to specify and verify concurrent 
algorithms. The use of TLA to specify and reason about open systems will 
be described elsewhere. 
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1 Logic versus Programming 



A concurrent algorithm is usually specified by a program. Correctness of the 
algorithm means that the program satisfies the desired property. Program, 
property, and satisfies are three separate concepts, so there are three things 
to define: a programming language, a language for expressing properties, 
and a satisfies relation. 

We propose a simpler approach in which both the algorithm and the 
property are specified by formulas in a single logic. Correctness of the algo- 
rithm means that the formula specifying the algorithm implies the formula 
specifying the property, where implies is ordinary logical implication. The 
three concepts program, property, and satisfies are replaced by the single 
concept logical formula. One concept is simpler than three. 

We are motivated not by an abstract ideal of elegance, but by the prac- 
tical problem of reasoning about real algorithms. Rigorous reasoning is the 
only way to avoid subtle errors in concurrent algorithms, and such reasoning 
is practical only if the underlying formalism is simple. 

How can we abandon conventional programming languages in favor of 
logic if the algorithm must be coded as a program to be executed? The 
answer is that we almost always reason about the abstract algorithm, not 
the concurrent program that is actually executed. A typical example is 
the distributed spanning-tree algorithm used in the Autonet local area net- 
work [22]. The algorithm can be described in about one page of pseudo-code, 
but its implementation required about 5000 lines of C code and 500 lines 
of assembly code. 1 Reasoning about 5000 lines of C would be a herculean 
task, but we can reason about a one-page abstract algorithm. By starting 
from a correct algorithm, we can avoid the timing-dependent synchroniza- 
tion errors that are the bane of concurrent programming. If the algorithms 
we reason about are not real, compilable programs, then they do not have 
to be written in a programming language. 

But, why replace a programming language by logic? Aren't programs 
simpler than logical formulas? The answer is no. Programs are complicated; 
logical formulas are simple. For example, consider the following three-line 
Pascal statement and the approximately equivalent three-line logical for- 
mula, which uses the convention that x' denotes the new value of x. 



1 Assembly code was needed because C has no primitives for sending messages across 
wires. 
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if a > b then if a > c then x 
:= a else a; := c else if 6 > c 
then x := b else a; := c 



x' = max(a, max(6, c)) 
where max(f,w) = if v > w then v 

else w 



Most readers will find the logical formula much easier to understand than 
the Pascal statement. 

Of course, we cheated. The logical formula is easier to understand be- 
cause it is formated better. But, we cheated to make a point. The reason 
people think programs are simpler than logical formulas is that program- 
mers are better at formating than logicians are. When properly formated, 
logical formulas are no harder to read than programs. 

Let us rewrite the Pascal statement and the logical formula in equally 
readable forms. 

x := max(a, max(6, c)) x' = max(a, max(6, c)) 

Many readers may think that the statement and the formula are equally 
simple. They are wrong. The formula is much simpler than the Pascal 
statement. Equality is a simple concept that five-year-old children under- 
stand. Assignment (: = ) is a complicated concept that university students 
find difficult. Equality obeys simple algebraic laws; assignment doesn't. If 
we assume that all variables are integer- valued, we can subtract the left-hand 
side from both sides of the formula to obtain the equivalent formula 

0 = max(a, max(6, c)) — x' 

Trying this with the Pascal statement yields the absurdity 
? 

0 := max(a, max(6, c)) — x 

The right-hand sides of the Pascal assignment and the logical formula may 
look the same, but they are quite different. In the logical formula, "max" 
represents a mathematical function. Mathematical functions are simple; 
American children learn about them at the age of twelve. In the Pascal for- 
mula, "max" is a Pascal function. Pascal functions are complicated, involv- 
ing concepts like call by reference, call by value, and aliasing; it is unlikely 
that many university students understand them well. 

Since real languages like Pascal are so complicated, methods for reason- 
ing about programs are usually based on toy languages. Although simpler 
than real programming languages, toy languages are more complicated than 
simple logic. Moreover, their resemblance to real languages can be dan- 
gerously misleading. Consider the naive programmer who wants a Pascal 
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procedure that reverses the order of 100-element arrays, so reverse(a, 6) sets 
a(0) to 6(99), sets a(l) to 6(98), and so on. He writes the procedure body 

for i := 0, 99 do a(i) := 6(99 - i) 

and uses his toy-language system to verify that it has the desired post- 
condition, believing that this means his Pascal procedure is correct. He will 
be surprised to discover that his program doesn't work because it contains 
the procedure call reverse(c, c). 

We do not mean to belittle programming languages. They are compli- 
cated because they have a difficult job to do. Logic can be based on simple 
concepts like mathematical functions. Programming languages cannot, be- 
cause they must allow reasonably simple compilers to translate programs 
into reasonably efficient code for complex computers. Real languages must 
embrace difficult concepts like the distinction between values and locations, 
which leads to call-by-reference arguments and aliasing — complications that 
have no counterpart in simple mathematics. Programming languages are 
necessary for writing real programs; but logic offers a simpler alternative for 
reasoning about concurrent algorithms. 

To offer a practical alternative to programming languages, a logic must 
be both simple and expressive. There is no point trading a programming 
language for a logic that is just as complicated and hard to understand. Fur- 
thermore, a logic that achieves simplicity at the expense of needed expres- 
siveness will be impractical because the formulas describing real algorithms 
will be too long and complicated to understand. 

The logic that we propose for reasoning about concurrent algorithms 
is the temporal logic of actions, abbreviated as TLA. It is simple enough 
that its syntax and complete formal semantics can be written in less than 
a page. Almost all of TLA — syntax, formal semantics, all derived notation 
used to express algorithms, and the axioms and proof rules used to rea- 
son about algorithms — appears in Figures 4 (page 21), 5 (page 22), and 9 
(page 45). (All that is missing from those figures are the rules for adding 
dummy variables, mentioned in Section 9.3.) 

Logic is a tool. Its true test comes with use. Although TLA can be de- 
fined formally in a few pages, such a definition would tell you nothing about 
how it is used. In this report, we develop TLA as a method of describing 
and reasoning about concurrent algorithms. We limit ourselves to simple 
examples, so we can only hint at how TLA works with real algorithms. 
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2 Closed versus Open Systems 



In this report, we consider closed systems. A closed system is one that is 
completely self-contained — in contrast to an open system, which interacts 
with its environment. Any real system is open; it does not eternally con- 
template its navel, oblivious to the outside world. But for many purposes, 
one can model the actual system together with its environment as a single 
closed system. Such an approach is usually adequate for reasoning about 
algorithms. However, some problems can be studied only in the context 
of open systems. For example, composing component systems to form one 
large system makes sense only for components that are open systems. 

TLA can be used to describe and reason about open as well as closed 
systems. But closed systems are simpler, and they provide a necessary 
foundation for the study of open systems. This report develops TLA and 
applies it to closed systems. Open systems will be discussed elsewhere. 

3 The Logic of Actions 

TLA is the combination of two logics: a logic of actions and a simple tem- 
poral logic. This section describes the logic of actions, Section 4 describes 
simple temporal logic, and Section 5 combines them into a logic called RTLA, 
which is refined in Section 6 to TLA. 

3.1 Values, Variables, and States 

Algorithms manipulate data. We assume a set Val of values, where a value is 
a data item. The set Val includes the booleans true and false, numbers such 
as 1, 7, and —14, strings like "abc", and sets like the set Bool of booleans and 
the set Nat of natural numbers. We won't bother to define Val precisely, but 
Note 2 1 will simply assume that it contains all the values needed for our examples. 

We think of algorithms as assigning values to variables. We assume an 
infinite set Var of variable names. We won't bother describing a precise 
syntax for generating variable names, but will use names like x and sera. 

A logic consists of a set of rules for manipulating formulas. To under- 
stand what the formulas and their manipulation mean, we need a semantics. 
A semantics is given by defining a semantic meaning \F\ to syntactic objects 
F in the logic. 

2 End notes appear on page 61. 
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The semantics of our logic will be defined in terms of states. A state is 
an assignment of values to variables — that is, a mapping from the set Var 
of variable names to the set Val of values. Thus a state s assigns a value 
s(x) to a variable x. 

We will write s{xj to denote s(x). Thus, we consider the meaning {xj of 
the variable a; to be a mapping from states to values, using a postfix notation 
for function application. States are a purely semantic concept; they are not 
part of the logic. 

3.2 State Functions and Predicates 

A state function is an expression built from variables and values — for ex- Note 2 

ample, x 2 + y — 3. The meaning [/] of a state function / is a mapping from 

the set St of states to the set Val of values. For example, [x 2 + y — 3] is 

the mapping that assigns to a state s the value (s[a;]) 2 + s{yj — 3. We use 

a postfix functional notation, letting s[/] denote the value that [/] assigns 

to state s. The semantic definition is 

4/1 = /(W:+]W (1) 

where /(V l v ' : denotes the value obtained from / by substituting 

s\v\ for v, for all variables v. (The symbol = means equals by definition.) 

A variable a; is a state function — the state function that assigns the value 
s{xj to the state s. The definition of [/] for a state function / therefore 
extends the definition of {xj for a variable x. 

A predicate is a boolean- valued state function — for example, x 2 = y — 3 Note 3 
and x G Nat. In other words, a predicate P is a state function such that 
s[P] equals true or false for every state s. We say that a state s satisfies a 
predicate P iff (if and only if) s[P] equals true. 

State functions correspond both to expressions in ordinary programming 
languages and to subexpressions of the assertions used in ordinary program 
verification. Predicates correspond both to boolean- valued expressions in 
programming languages and to assertions. 

3.3 Actions 

An action is any boolean- valued expression formed from variables, primed 
variables, and values — for example, x' + 1 = y and x — 1 ^ z' are actions, 
where x, y, and z are variables. 
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An action represents a relation between old states and new states, where 
the unprimed variables refer to the old state and the primed variables refer 
to the new state. Thus, y = x' + 1 is the relation asserting that the value 
of y in the old state is one greater than the value of x in the new state. An 
atomic operation of a concurrent program will be represented in TLA by an 
action. 

Formally, the meaning \A\ of an action A is a relation between states — 
a function that assigns a boolean s[«4]/ to a pair of states s, t. We define 
s[-4]i by considering s to be the "old state" and / the "new state", so s[«4]/ 
is obtained from A by replacing each unprimed variable v by and each 
primed variable v' by t{vj: 

s{A]t = ^(V V : sH/MH/uO (2) 

Thus, s\y = x' + l]i equals the boolean value s\y\ = t\x\ + 1. 

The pair of states s,t is called an 11 A step" iff s[«4]/ equals true. If 
action A represents an atomic operation of a program, then s, t is an A step 
iff executing the operation in state s can produce state /. 

3.4 Predicates as Actions 

We have defined a predicate P to be a boolean- valued state function, so s[P] 
is a boolean, for any state s. The predicate P can also be viewed as an action 
(a boolean- valued expression involving primed and unprimed variables) that 
contains no primed variables. Thus, s[P]/ is a boolean, which equals s[P], 
for any states s and /. A pair of states s,t is a P step iff s satisfies P. 

Recall that a state function is an expression built from variables and 
values. For any state function /, we define /' to be the expression obtained 
by replacing each variable v in / by the primed variable v': 

f ± /(VV:»» (3) 

If P is a predicate, then P' is an action, and s[P']/ equals t\P\ for any 
states s and /. 

3.5 Validity and Provability 

An action A is said to be valid, written |= A, iff every step is an A step. 
Formally, 

|=^4 = Vs,i G St : s{A}t 
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As a special case of this definition, if P is a predicate, then 



|= P = Vs £ St : s{Pj 



A valid action is one that is true regardless of what values one substitutes 
for the primed and unprimed variables. For example, the action 



is valid. The validity of an action thus expresses a theorem about values. 

A logic contains rules for proving formulas. It is customary to write h F 
to denote that formula F is provable by the rules of the logic. Soundness of 
the logic means that every provable formula is valid — in other words, that 
h A implies |= A. The validity of actions such as (4) is proved by ordinary 
mathematical reasoning. How this reasoning is formalized does not concern Note 4 
us here, so we will not bother to define a logic for proving the validity of 
actions. But, this omission does not mean such reasoning is unimportant. 
When verifying the validity of TLA formulas, most of the work goes into 
proving the validity of actions (and of predicates, a special class of actions). 
The practical success of any TLA verification system will depend primarily 
on how good it is at ordinary mathematical reasoning. 

3.6 Rigid Variables and Quantifiers 

Consider a program that is described in terms of a parameter n — for example 
an n-process mutual exclusion algorithm. An action representing an atomic 
operation of that program may contain the symbol n. This symbol does not 
represent a known value like 1 or "abc". But unlike the variables we have 
considered so far, the value of n does not change; it must be the same in the 
old and new state. 

The symbol n denotes some fixed but unknown value. A programmer 
would call it a constant because its value doesn't change during execution 
of the program, while a mathematician would call it a variable because it 
is an "unknown". We call such a symbol n a rigid variable. The variables 
introduced above will be called program variables, or simply variables. 

Rigid variables like n and values like the string "abc" are called constants. 
A constant expression is an expression like "abc" ^ n that is composed of 
constants. Constant expressions are ordinary mathematical formulas, and 
can be manipulated by the ordinary rules of mathematics. In particular, we 
can quantify over rigid variables. For example 





(4) 




(5) 
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is a constant expression containing the free rigid variable n and the bound 
rigid variable m. This expression is equal to the constant expression n = 0. 

We could give a formal semantics for constant expressions, defining the 
meaning of an expression like (5) in terms of other mathematical objects. 
However, the semantics of constant expressions is the basis of ordinary pred- 
icate calculus and is well known. We will therefore assume that the meaning 
of a constant expression is understood, and we will use constant expressions 
in defining the semantics of TLA. 

We generalize state functions and actions to allow arbitrary constants 
instead of just values. For example, if a; is a (program) variable and n a 
rigid variable, then x' = x + n is the action asserting that the value of x in 
the new state is n greater than its value in the old state. More precisely, the 
meaning \x' = x + ra] of this action is defined by 

s[x' = x + njt = t{xj = s{xj + n 

Thus, the semantics of state functions and actions are now given in terms 
of constant expressions rather than values. However, a state is still an 
assignment of values to variables. 

If A is an action and n a rigid variable, then 3n £ Nat : A is also an 
action — a boolean- valued expression composed of constants, variables, and 
primed variables. The definition of {AJ in Section 3.3 implies 

[3n £ Nat : Aj = 3n £ Nat : {Aj 

A constant expression exp is valid, denoted |= exp, iff it equals true 
when any values are substituted for its rigid variables — for example, |= (n £ 
Nat) (n + 1 > n). Since s[«4]/ is now a constant expression, not a boolean, 
we must generalize our definition of validity to 

\=A = Vs,i £ St : |= s{A}t 

for any action A. 



3.7 The Enabled Predicate 

For any action A, we define Enabled A to be the predicate that is true for a 
state iff it is possible to take an A step starting in that state. Semantically, 
Enabled A is defined by 

s{Enabled Aj = 3t £ St : s{A]t (6) 
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for any state s. The predicate Enabled A can be defined syntactically as 
follows. If v\, . . . , v n are all the (program) variables that occur in A, then 

Enabled A = 3ci, . . . , c n : A(ci/v[, . . . , c n /v' n ) 

where A(ci/v[, . . . , c n /v' n ) denotes the formula obtained by substituting the 
rigid variables c 4 - for all occurrences of the v[ in A. For example, 

Enabled (y = (x 1 ) 2 + n) = 3c : y = c 2 + n 

If action A represents an atomic operation of a program, then Enabled A 
is true for those states in which it is possible to perform the operation. 

4 Simple Temporal Logic 

An execution of an algorithm is often thought of as a sequence of steps, each 
producing a new state by changing the values of one or more variables. We 
will consider an execution to be the resulting sequence of states, and will 
take the semantic meaning of an algorithm to be the set of all its possible 
executions. Reasoning about algorithms will therefore require reasoning 
about sequences of states. Such reasoning is the province of temporal logic. 

4.1 Temporal Formulas 

A temporal formula is built from elementary formulas using boolean oper- 
ators and the unary operator □ (read always). For example, if E\ and Ei 
are elementary formulas, then ->E\ A □ ( — ■ _Z?2 ) an( i ^{E\ =>■ 0(Ei V E2)) are 
temporal formulas. We define simple temporal logic for an arbitrary class of 
elementary formulas. TLA will be defined later as a special case of simple 
temporal logic by specifying its elementary formulas. 

The semantics of temporal logic is based on behaviors, where a behavior 
is an infinite sequence of states. Think of a behavior as the sequence of states 
that a computing device might go through when executing an algorithm. (It 
might seem that a terminating execution would be represented by a finite 
sequence of states, but we will see in Section 6.5 why infinite sequences are 
enough.) 

We will define the meaning of a temporal formula in terms of the mean- 
ings of the elementary formulas it contains. Since an arbitrary temporal 
formula is built up from elementary formulas using boolean operators and 
the □ operator, and all the boolean operators can be defined in terms of A 
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and -., it suffices to define {F A G], [-.F], and {OF] in terms of {Fj and 
IGJ. 

We interpret a temporal formula as an assertion about behaviors. For- 
mally, the meaning [i* 1 ] of a formula F is a boolean- valued function on 
behaviors. We let (j{Fj denote the boolean value that formula F assigns to 
behavior a, and we say that a satisfies F iff (j{Fj equals true. 

The definitions of {F A GJ and {~^FJ are simple: 

a{F A G} 4 a{Fj/\alGj 

In other words, a behavior satisfies F A G iff it satisfies both F and G; and 
a behavior satisfies ->F iff it does not satisfy F. One can derive similar 
formulas for the other boolean operators. For example, since F =>■ G equals 
->(F A ->G), a straightforward calculation proves that a\F =>■ G] equals 

We now define \pF\ in terms of \F\. Let ((so, «i, «2 5 • • •)) denote the 
behavior whose first state is so, second state is si, and so on. Then 

{{s 0 ,s 1 ,s 2 ,..)){nF\ = Vra G Nat : (( 

»m (7) 

Think of the behavior ((so, . . .)) as representing the evolution of the universe, 
where s n is the state of the universe at "time" n. The formula ((so, . . 
asserts that F is true at time 0 of this behavior, and ((s n , . . -)){FJ asserts 
that it is true at time n. Thus, ((so, . . -M^-F] asserts that F is true at all 
times during the behavior ((so, . . .)). In other words, OF asserts that F is 
always true. 

4.2 Some Useful Temporal Formulas 
4.2.1 Eventually 

For any temporal formula F, let <0>F be defined by 

OF = -iD-i_F (8) 

This formula asserts that it is not the case that F is always false. In other 
words, OF asserts that F is eventually true. Since — ■'V — ■ is the same as 3, 

((so,si,s 2 , ...}}{<> F} = 3n e Nat : (( 

for any behavior ((so, «i, . . .)). Therefore, a behavior satisfies OF iff F is 
true at some time during the behavior. 
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4.2.2 Infinitely Often and Eventually Always 

The formula O<0>F is true for a behavior iff O-F is true at all times n during 
that behavior, and O-F is true at time n iff F is true at some time to greater 
than or equal to n. Formally, 

((s 0 ,si,...))[nOF] = Vn G Nat : 3m G Nat : ((s n+m , s n+m+1 , . . .)){F] 

A formula of the form Vn : 3m : g(n + to) asserts that g(i) is true for 
infinitely many values of i. Thus, a behavior satisfies O<0>F iff F is true 
at infinitely many times during the behavior. In other words, O<0>F asserts 
that F is true infinitely often. 

The formula K>OF asserts that eventually F is always true. Thus, a 
behavior satisfies K>OF iff there is some time such that F is true from that 
time on. 

4.2.3 Leads To 

For any temporal formulas F and G, we define F G to equal 0(F =>■ OG). 
This formula asserts that any time F is true, G is true then or at some 
later time. The operator (read leads to) is transitive, meaning that any 
behavior satisfying F G and G ^ H also satisfies F ^ H . We suggest 
that the reader convince himself both that is transitive, and that it would 
not be had F G been defined to equal F =>■ OG. 

4.3 Validity and Provability 

A temporal formula F is said to be valid, written |= F, iff it is satisfied by 
all possible behaviors. More precisely, 

|= F = V<7 G St°° : a{Fj (9) 

where St°° denotes the set of all behaviors (infinite sequences of elements 
of St). 

We will represent both algorithms and properties as temporal formulas. 
An algorithm is represented by a temporal formula F such that (j{Fj equals 
true iff a represents a possible execution of the algorithm. If G is a temporal 
formula, then F =>■ G is valid iff a\F =>■ GJ equals true for every behavior a. 
Since a\F =>■ GJ equals (j{Fj =>■ validity of _F =>■ G means that every 

behavior representing a possible execution of the algorithm satisfies G. In 
other words, |= F =>■ G asserts that the algorithm represented by F satisfies 
property G. 
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In Section 6.6, we give rules for proving temporal formulas. As usual, 
soundness of the rules means that every provable formula is valid — that is, 
h F implies |= F for any temporal formula F. 

5 The Raw Logic 

5.1 Actions as Temporal Formulas 

The Raw Femporal Logic of Actions, or RTLA, is obtained by letting the 
elementary temporal formulas be actions. To define the semantics of RTLA 
formulas, we must define what it means for an action to be true on a behav- 
ior. 

In Section 3.3, we defined the meaning {AJ of an action A to be a 
boolean- valued function that assigns the value s[«4]i to the pair of states 
s,t. We defined s,t to be an A step iff s[«4]i equals true. We now define 
{AJ to be true for a behavior iff the first pair of states in the behavior is an 
Note 5 A step. Formally, 

((s 0 , Sl ,s 2 ,...))lA] = s 0 lA] Sl (10) 

RTLA formulas are built up from actions using logical operators and the 
temporal operator □. Thus, if ^4 is an action, then OA is an RTLA formula. 
Its meaning is computed as follows. 

((so,si,s 2 ,...»[n^] 

= Vra £ Nat : ((s n ,s n+1 ,s n+2 , . . .)){A} {by (7)} 

= Vra £ Nat : s n {Ajs n+1 {by (10)} 

In other words, a behavior satisfies OA iff every step of the behavior is an 
A step. 

In Section 3.4, we observed that if P is a predicate, then s[P]/ equals 
s[P]. Therefore, 

((s 0 , Sl ,...))lP] = s 0 {P] 
(( So ,5i,...»[DP] = VnGNat:s„[P] 

In other words, a behavior satisfies a predicate P iff the first state of the 
behavior satisfies P. A behavior satisfies OP iff all states in the behavior 
satisfy P. 

We will see that the raw logic RTLA is too powerful; it allows one to 
make assertions about behaviors that should not be assertable. We will 
define the formulas of TLA to be a subset of RTLA formulas. 
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var natural x, y = 0 ; 
do ( true — ► x := x + 1 ) 

D 

( true — ► y := y + 1 ) od 

Figure 1: Program 1 — a simple program, written in a conventional language. 

5.2 Describing Programs with RTLA Formulas 

We have defined the syntax and semantics of RTLA formulas, but have given 
no idea what RTLA is good for. We illustrate how RTLA can be used by de- 
scribing the simple Program 1 of Figure 1 on this page as an RTLA formula. 
This program is written in a conventional language, using Dijkstra's do con- 
struct [7], with angle brackets enclosing operations that are assumed to be 
atomic. An execution of this program begins with x and y both zero, and 
repeatedly increments either x or y (in a single operation), choosing non- 
deterministically between them. We will define an RTLA formula $ that 
represents this program, meaning that will equal true iff the behavior 

a represents a possible execution of Program 1. 

The formula $ is defined in Figure 2 on the next page. The predicate 
Initq, asserts the initial condition, that x and y are both zero. The semantic 
meaning of action .Mi is a relation between states asserting that the value 
of x in the new state is one greater than its value in the old state, and 
the value of y is the same in the old and new states. Thus, an Ai\ step 
represents an execution of the program's atomic operation of incrementing 
x. Similarly, an A^2 step represents an execution of the program's other 
atomic operation, which increments y. The action Ai is defined to be the 
disjunction of Ai\ and Ai 2 , so an Ai step represents an execution of one 
program operation. The formula $ is true of a behavior iff Initq, is true of 
the first state and every step is an Ai step. In other words, $ asserts that 
the initial condition is true initially, and that every step of the behavior 
represents the execution of an atomic operation of the program. Clearly, a 
behavior satisfies $ iff it represents a possible execution of Program 1. Note 6 

There is nothing special about our choice of names, or in the particu- 
lar way of writing There are many ways of writing equivalent logical 
formulas. Here are a couple of formulas that are equivalent to 

(x = 0) A a(M 1 VM 2 ) A (y = 0) 

Initq, A D((V = x + 1) V (y' = y + 1)) A D((V = x) V (y' = y)) 
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Initq, = (x = 0) A (y = 0) 

Mr = (x' = x + 1) A (y' = y) M 2 = (y' = y + 1) A (x' = x) 
M = MxV M 2 
$ = Initq, A UM 

Figure 2: An RTLA formula $ describing Program 1. 

The particular way of defining $ in Figure 2 was chosen to make the corre- 
spondence with Figure 1 obvious. 



6.1 The Example Program Revisited 

Formula $ of Figure 2 is very simple. Unfortunately, it is too simple. In 
addition to steps in which x or y is incremented, a formula describing Pro- 
gram 1 should allow "stuttering" steps that leave both x and y unchanged. 
Allowing these stuttering steps may seem strange now, but later it will be- 
come clear why we need them. 

It is easy to modify $ so it asserts that every step is either an Ai step 
or a step that leaves x and y unchanged; the new definition is 



We now introduce notation to make such formulas easier to write. Two 
ordered pairs are equal iff their components are equal, so the conjunction 
(x 1 = x) A (y' = y) is equivalent to the single equality (x',y') = (x,y). The 
definition of priming a state function (formula (3) on page 6) allows us to 



Note 7 write (x',y') as (x,y)'. For any action A and state function /, we let 



6 TLA 



$ = Initq, A a(M V ((V = x) A (y' = y))) 



(11) 



[A] f 4 Aw(f' = f) 



(12) 



(The action [A]f is read square A sub f.) Then 



[M] {Xiy) = M V ((x,y)' = (x,y)) 

= M V ((x 1 = x) A (y 1 = y)) 



and we can rewrite (11) as 



$ = Initq, A □[A4]( :E)2/ ) 



(13) 
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We define TLA to be the temporal logic whose elementary formulas are 
predicates and formulas of the form d[-4]/, where A is an action and / a 
state function. Since these formulas are RTLA formulas, we have already 
defined their semantic meanings. 

6.2 Adding Liveness 

The formula $ defined by (13) allows behaviors that start with Initq, true (x 
and y both zero) and never change x or y. Such behaviors do not represent 
acceptable executions of Program 1, so we must strengthen $ to disallow 
them. 

Formula $ of (13) asserts that a behavior may not start in any state 
other than one satisfying Initq, and may never take any step other than 
a [A^]^^) step. An assertion that something may never happen is called 
a safety property. An assertion that something eventually does happen is 
called a liveness property. (Safety and liveness have been defined formally 
by Alpern and Schneider [3].) The formula Initq, A n[M]( Xty ) is a safety 
property. To complete the description of Program 1, we need an additional 
liveness property asserting that the program keeps going. 

By Dijkstra's semantics for his do construct, the liveness property for 
Program 1 should assert only that the program never terminates. In other 
words, Dijkstra would require that a behavior must contain infinitely many 
steps that increment x or y. This property is expressed by the RTLA formula 
□ which asserts that there are infinitely many Ai steps. Dijkstra would 
have us define $ by 



However, the example becomes more interesting if we add the fairness re- 
quirement that both x and y must be incremented infinitely often. (Di- 
jkstra's definition would allow an execution in which one variable is incre- 
mented infinitely often while the other is incremented only a finite number 
of times.) Since we are not fettered by the dictates of conventional pro- 
gramming languages, we will adopt this stronger liveness requirement. The 
formula $ representing the program with this fairness requirement is 



Formulas (14) and (15) are RTLA formulas, but not TLA formulas. An 
action A can appear in a TLA formula only in the form d[-4]/, so nOA^i 
and dOA^ are n °t TLA formulas. We now rewrite them as TLA formulas. 



$ = Initq, A U[M\ x ^ y) A a<>M 



(14) 



$ = Initq, A U[M\ x , y ) A UOMi A UOM 2 



(15) 
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Let A be any action and / any state function. Then ->A is also an action, 
so [-1.4] j is a TLA formula. Applying our definitions gives 

= <>—■[— 1^4.]/ {by (8), which implies -.□... = O-... .} 

= 0-(^4V (/' = /)) {by (12)} 

= 0(A A (/' ^ /)) {by simple logic} 

We define the action (A) / (read angle A sub f ) by 

(A) f ± AA(f^f) (16) 

The calculation above shows that < 0>(A)f equals -iD[-i„4]y, so it is a TLA 
formula. 

Since incrementing a variable changes its value, both A4\ and A^2 imply 
Note 8 (x,y)' (x,y). Hence, A4\ is equivalent to {Mi)( Xty ), and A^2 is equivalent 
to (M2)( x ,y)- We can therefore rewrite $ as a TLA formula as follows. 

$ = Init* A n[M] {Xiy) A □0(>1 1 ) ( ^ ) A DO(M 2 )( x ,y) (17) 



6.3 Fairness 

The liveness condition □0(A / li)( :r , j j / ) A U<yl K M. 2 )(x,y) f° r Program 1 is very 
simple. In realistic examples, liveness conditions are not always so simple. 
We now rewrite this condition in a more general form that can be used to 
express most of the liveness conditions that arise in practice. 

Liveness conditions of concurrent algorithms are expressed by fairness 
properties. Fairness means that if a certain operation is possible, then the 
program must eventually execute it. To our knowledge, all fairness condi- 
tions that have been proposed fall into one of two classes: weak fairness and 
strong fairness. We first define weak and strong fairness informally, then 
translate the informal definitions into TLA formulas. 

Weak fairness asserts that an operation must be executed if it remains 
possible to do so for a long enough time. "Long enough" means until the 
operation is executed, so weak fairness asserts that eventually the operation 
must either be executed or become impossible to execute — perhaps only 
briefly. A naive temporal-logic translation is 

weak fairness: (O executed) V (O impossible) 

Strong fairness asserts that the operation must be executed if it is often 
enough possible to do so. Interpreting "often enough" to mean infinitely 
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often, strong fairness asserts that either the operation is eventually executed, 
or its execution is not infinitely often possible. Not infinitely often possible 
is the same as eventually always impossible (because (8) implies -idO . . . = 
On-i . . .), so we get 

strong fairness: (O executed) V (On impossible) 

These two temporal formulas assert fairness at "time zero" , but we want 
fairness to hold at all times. The correct formulas are therefore 

weak fairness: a ((0 executed) V (O impossible)) 
strong fairness: 0((0 executed) V (On impossible)) 

Temporal-logic reasoning, using either the axioms in Section 6.6 or the se- 
mantic definitions of □ and O, shows that these conditions are equivalent 
to 

weak fairness: (DO executed) V (DO impossible) 
strong fairness: (DO executed) V (On impossible) 

To formalize these definitions, we must define "executed" and "impossible". 

In Program 1, execution of the operation x := x + 1 corresponds to an 
Ai\ step in the behavior. To obtain a TLA formula, the "O executed" for 
this operation must be expressed as 0(A / 1i)( :Ej j / ). In general, "O executed" 
will be expressed as <0>(A)f, where A is the action that corresponds to an 
execution of the operation, and / is an ra-tuple of relevant variables. Recall 
that an (A) / step is an A step that changes the value of /. Steps that do not 
change the values of any relevant variables might as well not have occurred, 
so there is no need to consider them as representing operation executions. 

We now define "impossible". Executing an operation means taking an 
(A) f step for some action A and state function /. It is possible to take such 
a step iff Enabled (A) / is true. Thus, Enabled (A) / asserts that it is possible 
to execute the operation represented by the action {A)f, so "impossible" is 
^Enabled {A)f. 

Weak fairness and strong fairness are therefore expressed by the two 
formulas 



WF f (A) 
SF f (A) 



A 



(aO(A}f) V (DO-, Enabled (A) f ) 
(nO(A) f ) V {OU^Enabled (A)/) 



(18) 
(19) 



A 
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Initq, = (x = 0) A (y = 0) 

Mr = (x' = x + 1) A (y' = y) M 2 = (y' = y + 1) A (x' = x) 
M = MxV M 2 

$ 4 Mi* A a[M] (X)y) A WF^M^ A WF {X)y) (M 2 ) 

Figure 3: The TLA formula $ describing Program 1. 

6.4 Rewriting the Fairness Condition 

We now rewrite the property □0(A / 1i)( :Ej j / ) ADO(A / l2)(^,j/) m terms of fairness 
conditions. An (M-i)[ x ,y) s ^ e P 1S one that increments x by one, leaves y 
unchanged, and changes the value of (x,y). It is always possible to take 
a step that adds one to x and leaves y unchanged, and adding one to a 
number changes it. Hence, Enabled (M-i)[ x ,y) equals true throughout any 
Note 9 execution of Program 1. Since □-■true equals false, both WF^^^Aii) and 
SF {Xty) {M{) equal DO^i)^). Similarly, WF^A^) and SF^A^) 
both equal 0<>(J\A 2 )( Xjy y We can therefore rewrite the definition (17) of $ 
as shown in Figure 3 on this page. 

Suppose we wanted the weaker liveness condition that execution never 
terminates, so the program is described by the RTLA formula (14) on 
page 15. The same argument as for Ai\ and Ai 2 shows that □0(A / 1 )[ x ,y) 
equals WF^ :y )(-M )• Therefore, Program 1 with this weaker liveness condi- 
tion is described by the TLA formula Init® A □[.M]( :E)2/ ) A WF^^Al ). 

6.5 Examining Formula $ 

TLA formulas that represent programs can always be written in the same 
form as $ of Figure 3 — that is, as a conjunction Init A d[A/]/ A F, where 

Init is a predicate specifying the initial values of variables. 

A/ is the program's next-state relation, the action whose steps represent 
executions of individual atomic operations. 

/ is the ra-tuple of all program variables. 

F is the conjunction of formulas of the form WF/(«4) and/or SF/(«4), where 
A is an action representing some subset of the program's atomic op- 
erations. 
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We now examine the behaviors that satisfy formula Let 
(0 = 7, y = -10, z = "abc", . . .)) 

denote a state s such that s{xj = 7, s{yj = —10, and s{zj = "abc". (The 
". . ." indicates that the value of s{v ] is left unspecified for all other variables 
v .) A behavior that satisfies $ begins in a state satisfying Init®, and consists 
of a sequence of [A^]^^) steps — ones that are either Ai steps or else leave 
x and y unchanged. One such behavior is 

| x = 0, y = 0, z = abc . . . J 

( x = 1, y = 0, z = true • • • J 

( a; = 2, y = 0, z = true • • • J 

(( x = 2, y = 0, z = -20 . . . )) 

(( a; = 2, y = 1, ^ = Nat • • • )) 



Observe that $ constrains only the values of x and y; it allows all other vari- 
ables such as z to assume completely arbitrary values. Suppose $ is a for- 
mula describing a program that has no variables in common with Then a 
behavior satisfies $ A $ iff it represents an execution of both programs — that 
is, iff it describes a universe in which both $ and $ are executed concur- 
rently. Thus, $ A$ is the TLA formula representing the parallel composition 
of the two programs. In the realm of closed systems, conjunction represents 
parallel composition only in special cases — for example, when the programs 
do not interact, so they are represented by TLA formulas with no variables 
in common. The desire to make conjunction represent parallel composition Note 10 
for interacting programs guides our approach to open systems, but that is 
a topic to be discussed elsewhere. 

The observation that a single behavior can represent an execution of two 
or more noninteracting programs explains why we represent terminating as 
well as nonterminating executions by infinite behaviors. Termination of a 
program means that it has stopped; it does not mean that the entire universe 
has come to a halt. A terminating execution is represented by a behavior in 
which eventually all of the program's variables stop changing. 

It is unusual in computer science for the semantics of a formula describing 
a program with variables x and y to involve other variables such as z. One 
of the keys to TLA's simplicity is that its semantics rests on a single, infinite 
set of variables — not on a different set of variables for each program. Thus, 
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in TLA as in elementary logic, we can take the conjunction F A G and 
negation ->F of any formulas F and G — not just of formulas with properly 
matching variable declarations. 

6.6 Simple TLA 

We now complete the definition of Simple FLA by adding one more bit of 
notation. (The full logic, containing quantification, is introduced in Sec- 
tion 9.) It is convenient to define the action Unchanged /, for / a state 
function, by 

Unchanged f = f = f 

Thus, an Unchanged f step is one in which the value of / does not change. 

The syntax and semantics of Simple TLA, along with the additional 
notation we use to write TLA formulas, are all summarized in Figure 4 on 
the next page. This figure explains all you need to know to understand TLA 
formulas such as formula $ of Figure 3. 

A logic contains not only syntax and semantics, but also rules for proving 
theorems. Figure 5 on page 22 lists all the axioms and proof rules we need 
for proving simple TLA formulas. 3 We will not prove the soundness of these 
rules here. 

The rules of simple temporal logic are used to derive temporal tautolo- 
gies — formulas that are true regardless of the meanings of their elementary 
Note 11 formulas. Rule STL1 encompasses the rules of ordinary logic, such as modus 
ponens. The Lattice Rule assumes a (possibly infinite) nonempty set of 
formulas H c indexed by elements of a set S. A partial order y on S is 
well-founded iff there exists no infinite descending chain ci y ci y . . . with 
all the Ci in S. This rule permits the formalization of counting-down argu- 
ments, such as the ones traditionally used to prove termination of sequential 
programs. 

Rules STL1-STL6, the Lattice Rule, and the basic rules TLA1 and TLA2 
form a relatively complete proof system for reasoning about algorithms in 
TLA. Roughly speaking, this means that every valid TLA formula that 
we must prove to verify properties of algorithms would be provable from 
these rules if we could prove all valid action formulas. (This is analogous to 
the traditional relative completeness results for program verification, which 

3 A proof rule ^ asserts that h F implies h G. We use the term "rule" for both axioms 
and proof rules, since an axiom may be viewed as a proof rule with no hypotheses. 
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Syntax 

(formula ) 

(action) 

(predicate) 
(state function) 

Semantics 

4/1 =/(W:+]W a \F AG] = cr{F} A a{GJ 

s{A]t 4 yl(V V : sM/v, tM/v') a^F] 4 ^[F] 

|=„4 = Vs,i G St :|= s{A]t \= F = Vd G St°° :|= 



(predicate) \ ^[(action)\ sUU functwn ) \ -^(formula) 

| (formula) A (formula) | □ (formula) 
boolean- valued expression containing constants, 

variables, and primed variables 
boolean- valued (state function) \ Enabled (action) 
expression containing constants and variables 



A 



s{Enabled Aj 
((s 0 , Sl ,...))lDFl 

((s 0 , Sl ,...))l-Al 

Additional notation 

/' = /(V V : v'/v) 
[A] f ± A\/(f = f) 

Unchanged f = f = f 



where / is a (state function) 
A is an (action) 
F, G are (formula)^ 



3t G St : s{Ajt 

Vra G Nat : ((s n , s n+1 , . . .)){F] 

solA}s 1 



OF 

WF f (A) 
SF f (A) 



A_ 
A_ 
A_ 
A 



-iD-iF 

n(F=>OG) 

aO(A)j V OO^Enabled (A) f 
aO(A)j V OO^Enabled (A) f 



s, so, si, • 



are states 
a is a behavior 

(V l v ' : . . ./f, . . . denotes substitution 
for all variables v 



Figure 4: Simple TLA. 
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The Rules of Simple Temporal Logic 

STL1. F provable by STL4. F G 

propositional logic 

I— l_f =/- l— l(jr 

F 

STL2. h OF =>■ F STL5. h D(P A G) = (DP) A (□£) 

STL3. h DDF = DP STL6. h (OOP) A (OnG) = On(FAG) 

LATTICE. >- well-founded partial order on nonempty set S 

F A (c G S) (i? c ~> (G V 3d G S : (c y d) A i? d )) 
F => ((3c G S : H c ) G) 



The Basic Rules of TLA 

TLA1. h op = P/\a[P=>P']p 



Additional Rules 

INV1. lA[Af] f ^I' 
I A □ / 

WF1. 

PA [TV]/ => (P'VQ') 
PA(/VA.4}/ => 0' 
P =>• Enabled (A) / 



SF1. 

PA [TV]/ => (P'VQ') 

pa(/Va.4}/ => 0' 

□ PA □ [TV]/ A DP => O Enabled (A)j 

□ [TV]/ ASF/ (A) A DP => 



where F, G, P c are TLA formulas 
A, B, A/", Ai are actions 



TLA2. P A [A] f Q A 

□ P A D^]/ DQ A D[B] g 

INV2. h □ / => (□[TV]/ = DfyVA/A/']/) 

WF2. 

(TV AS}/ => (M)j 

P AP' A (TV AA) f => B 

P A Enabled (M) g => Enabled (A) / 

□ [A" A ->B]f A WF / (.4) A OF => OOP 

□ [TV]/ A WFf(A) A OF => WFg(M) 

SF2. _ 

(TV AS}/ => <A% 

P AP' A{N AA) S => B 

P A Enabled (M) g => Enabled (A) / 

□ [7VA-S]/ ASF/(_4)ADF => OOP 

□ [TV]/ ASF/ (A) A OF => SF g (M) 

P, Q, I are predicates 
/, g are state functions 



Figure 5: The axioms and proof rules of Simple TLA. 
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assume provability of all valid predicates [4].) The precise statement and 
proof of the completeness theorem will appear elsewhere. 

A complete proof system is not necessarily a convenient one. There 
are a number of rules that are useful in practice but are either difficult or 
impossible to derive from STL1-TLA2. For a practical system, STL1-STL6 
should be expanded to include some useful temporal tautologies like 

h (OF) A(OG) O(FAG) 

With practice, such simple tautologies become as obvious as the ordinary 
laws of propositional logic, and they are usually assumed in proofs that are 
not machine- checked. We will not bother to provide a complete list of the 
useful rules and theorems of simple temporal logic. 

Assuming simple temporal reasoning, we have found that TLA2 and the 
"additional rules" INV1-SF2 of Figure 5 provide a convenient system for all 
the proofs that arise in reasoning about programs with TLA. The overbars 
in rules WF2 and SF2 are explained in Section 9.3; for now, the reader can 
pretend that they are not there, obtaining special cases of the rules. 

We do not know how to prove "practical completeness", and there are 
probably examples in which TLA2 and INV1-SF2 are inadequate, compli- 
cated reasoning with TLA1 and TLA2 being necessary. However, we have 
not yet encountered such examples and we believe they will be rare. 

7 Proving Simple Properties of Programs 

Having expressed Program 1 of Figure 1 as the TLA formula $ of Figure 3, 
we now consider how to express and prove properties of such a program. 
A property is expressed by a TLA formula F. The assertion "program $ 
has property P" is expressed in TLA by the validity of the formula $ =>■ F, 
which asserts that every behavior satisfying $ satisfies F. We consider two 
popular classes of properties, invariance and eventuality. 

7.1 Invariance Properties 
7.1.1 Definition 

An invariance property is expressed by a TLA formula DP, where P is a 
predicate. Examples of invariance properties include 

partial correctness P asserts that if the program has terminated, then 
the answer is correct. 
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deadlock freedom P asserts that the program is not deadlocked. 

mutual exclusion P asserts that at most one process is in its critical sec- 
tion. 

Invariance properties are proved with rule INV1 of Figure 5. Its hypothesis 
asserts that any [AT]f step starting with / true in the old state leaves / true 
in the new state. The conclusion asserts that, for any behavior that starts 
in a state with / true and has only [AT]f steps, / is true in all states. The 
soundness of this deduction is proved by a simple induction argument. 

7.1.2 An Example: Type Correctness 

One part of the program in Figure 1 does not correspond to anything in 
Figure 3 — the type declaration of the variables x and y. Such a declara- 
tion is not needed because type-correctness is an invariance property of the 
program, asserting that x and y are always natural numbers. We illustrate 
invariance proofs by proving type correctness of Program 1. Type correct- 
ness is expressed formally as $ OT, where 



T = (x £ Nat) A (y G Nat) 

Rule INV1 tells us that we must prove 

Initq, =>■ T 
TA[M] {x , y) ^T' 



(20) 

(21) 
(22) 



from which we deduce $ =>■ OT as follows 

$ Init$ A DlyVf]^) {by definition of $ (Figure 3)} 

TAU[M] {Xty) ' {by (21)} 

=>- UT {by (22) and INV1} 

The proof of (21) is trivial. The proof of (22) is quite simple, but we will 
sketch it to show how the structure of the formulas leads to a natural de- 
composition of the proof. First, we expand the definition of [A^]^ ^. 

[M] {X:y) = MV((x, y y = (x,y)) {by (12)} 

= Mi V M 2 V ((x, y)' = (x, y)) {by definition of M} 
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Since [A^]^^) is the disjunction of three actions, the proof of (22) decom- 
poses into the proof of three simpler formulas: 

T A Mi T' (23) 

TAM 2 T' (24) 

TA((x,y)' = (x,y)) T' (25) 

We consider the proof of (23); the others are equally simple. First, we 
expand the definition of T'. 

T' = {{x G Nat) A (y G Nat))' {by (20)} 

= (V G Nat) A (y' G Nat) {by (3)} 

The structure of T' as the conjunction of two actions leads to the decompo- 
sition of the proof of (23) into the proof of the two simpler formulas 

T A Mi x' G Nat (26) 

T A Mi y' G Nat (27) 

The proof of (26) is 

T A Mi => (x G Nat) A (x 1 = X + 1) {by definition of T and Mi} 

=>■ X 1 G Nat {by properties of natural numbers} 

and the proof of (27) is equally trivial. 

The purpose of this exercise in simple mathematics is to illustrate how 
"mechanical" the proof of this invariance property is. Rule INV1 tells us 
we must prove (21) and (22), and the structure of [A^]^^) and T leads to 
the decomposition of those proofs into the verification of simple facts about 
natural numbers, such as (x G Nat) =4> (x + 1 G Nat). 

7.1.3 General Invariance Proofs 

The proof of $ OT was simple because T is an invariant of the action 
[A^]^^), meaning that T A [M]( Xjy ) implies T' . Therefore, $ =>■ OT could 
be proved by simply substituting T for / in rule IN VI. For invariance prop- 
erties OP other than simple type correctness, P is usually not an invariant. 
In general, one proves that OP is an invariance property of the program 
represented by the TLA formula Init A d[A/]/ A F by finding a predicate / 
(the invariant) satisfying the three conditions 

Init =>• / (28) 
I=>P (29) 
lA[Af] f ^l' (30) 
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Rule INV1 and some simple temporal reasoning shows that (28)-(30) imply 
Init A n[AT] f => OP. 

Creative thought is needed to find the invariant I. Once / is found, 
verifying (28)-(30) is a matter of mechanically applying the definitions and 
using the structure of the formulas to decompose the proofs, just as in the 
proof of $ =>■ OT above. The formulas Init, I, and Af will usually be much 
more complicated than in the example, but the principle is the same. 

Formulas (28)-(30) are assertions about predicates and actions; they are 
not temporal formulas. All the work in proving an invariance property is 
done in the realm of predicates and actions — expressions involving variables 
and primed variables that can be manipulated by ordinary mathematics. 
Temporal reasoning is used only to deduce Init A 0[AT]f =>■ DP from (28)- 
(30). It is this reduction of temporal properties to ordinary, nontemporal 
reasoning that makes TLA practical. 

7.1.4 More About Invariance Proofs 

Over the years, many methods have been proposed to prove invariance prop- 
erties of programs, including Floyd's method [10], Hoare logic [13], and the 
Owicki-Gries method [19]. All of these methods are essentially the same — 
when applied to the same program, they involve the same proof steps, though 
perhaps in different orders and with different notation. These methods can 
be described formally in TLA as applications of rule IN VI. The advantage 
of TLA is that the proof method arises directly from the logic, without the 
need for proof rules based on a particular programming language. 

We illustrate the advantage of working in a simple logic by considering 
the use of one invariance property to prove another. We have just proved 
$ =>• OT, the assertion that the program satisfies the invariance property 
□ T. How can we use this fact when proving that the program satisfies a 
second invariance property DP? Some methods have a special rule saying 
that if a program satisfies OT, then one can pretend that T is true when 
reasoning about the program. (The "substitution axiom" of Unity [6] is 
such a rule.) In TLA, we use Rule INV2 of Figure 5. This rule implies that 
having proved $ =>■ OT, we can rewrite the definition of $ in Figure 3 as 

$ = Init* A □[MATAf] M A WF ( ^ ) (>1 1 ) A WF {Xiy) (M 2 ) 

It follows that in proving $ implies OP, instead of assuming every step to 
be a [A^]^^) step, we can make the stronger assumption that every step is a 
[Ai AT A T']^ x ^ step. More precisely, we can substitute Ai AT AT' instead 
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of Ai for Af in rule INV1, giving a stronger proof rule. This stronger rule is 
tantamount to "pretending T is true". The validity of this pretense follows 
directly from the logic; it is not an ad hoc rule. 

7.1.5 More About Types 

In TLA, variables have no types. Any variable can assume any value. Type- 
correctness of a program is a provable property, not a syntactic requirement 
as in strongly-typed programming languages. This has some subtle conse- 
quences. Consider the action x' = x + 1. Its meaning is a boolean- valued 
function on pairs of states. Suppose s and / are states that assign the values 
"abc" and true to x, respectively — that is, so s{xj equals "abc" and t{xj 
equals true. Then s\x' = x + 1]/ equals true = "abc" + 1. But what is 
"abc" + 1? Does it equal true? 

We don't know the answers to these questions, and we don't care. All 
we know is that "abc" + 1 is some value. Since that value is either equal to 
or unequal to true, the expression true = "abc" + 1 is equal to either true 
or false. More precisely, we assume that m + n is an element of the set Val 
of values, for any m and n in Val. However, we have no rules for deducing 
anything about the value of m + n except when m and n are numbers. In 
general, we assume that all functions such as "+" are total — their domains 
include all elements of Val, and their range is (a subset of) Val. What we 
usually think of as the domain of a function is just the set of values for which 
we know how to evaluate the function. We know how to evaluate p A q only 
when p and q are elements of the set Bool of booleans, but it is defined (in 
the mathematical sense of being a meaningful expression) for all values p 
and q. 

Since we can't deduce anything about the value "abc" + 1, whatever we 
prove about an algorithm is true regardless of what that value is. If we can 
prove that the program is correct, then either it will never add 1 to "abc" 
(as in the case of Program 1), or else correctness does not depend on the 
result of that addition. 

This approach may seem strange to computer scientists used to types 
in programming languages, but it captures the way mathematicians have 
reasoned for thousands of years. For example, mathematicians would say 
that the formula 

(n G Nat) => (n + 1 > n) 
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is true for all n. Substituting "abc" for n yields 

("abc" G Nat) ("abc" + 1 > "abc") 

This formula equals true regardless of what "abc" + 1 equals, and whether or 
Note 12 not that value is greater than "abc", because "abc" £ Nat equals false. The 
formula is not meaningless or "type-incorrect" just because we don't know 
the value of "abc" + 1; we don't need any complicated three- valued logic to 
understand the formula. 

Types are a useful feature in programming languages, but they are a 
needless complication when reasoning about algorithms. Logic should be 
simple, and one of the ways we keep TLA simple is by not complicating it 
with any notion of types. 

We have found computer scientists to be skeptical of our eliminating 
types from logic. They seem to feel that type-checking is easier than proving 
a property like OT. This is nonsense. Type-checking the program of Figure 1 
is logically equivalent to proving the TLA formula $ =>■ OT, so a type- 
checker must perform exactly the same reasoning that we did. Adding strong 
typing to the logic would mean that a TLA formula would be type-correct 
only if the proof of the corresponding invariance property were so trivial that 
it could be done automatically. If type-correctness of the program were not 
completely trivial, so its proof required even the tiniest bit of intelligence, 
then strong typing would prohibit us from expressing it in the logic. 

We can assure the reader that, just as mathematics thrived for thousands 
of years without type theory, logic works fine without types. Experience has 
taught us that adding types would only make TLA less convenient to use. 
The absence of types in TLA does not prevent mechanized type checking. 
One can still write a program that tries to prove the TLA formula represent- 
ing type correctness, and complains if it fails. But only an intelligent human 
can determine if the type checker failed because of its stupidity, or because 
the TLA formula is invalid. If he expects to verify interesting properties of 
concurrent algorithms, our human had better be intelligent enough to prove 
simple type correctness. 

7.2 Eventuality Properties 

The second class of properties we consider are eventuality properties — ones 
asserting that something eventually happens. Here are some traditional 
eventuality properties and their expressions in temporal logic: 

termination The program eventually terminates: O terminated. 
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service If a process has requested service, then it eventually is served: 
requested served. 

message delivery If a message is sent often enough, then it is eventually 
delivered: (DO sent) =>■ O delivered. 

Although eventuality properties are expressed by a variety of temporal for- 
mulas, their proofs are always reduced to the proof of leads-to properties — 
formulas of the form P Q. For example, suppose we want to prove that 
Program 1 increases the value of x without bound. The TLA formula to be 
proved is 



The Lattice Rule of Figure 5 together with some simple temporal reasoning 
shows that (31) follows from 



To illustrate the use of TLA in proving leads-to properties, we now sketch 
the proof of (32). 

Since safety properties don't imply that anything ever happens, leads-to 
properties must be derived from the program's fairness condition. Examin- 
ing Figure 5 leads us to try rule WF1, with the following substitutions: 

P <— n G Nat A x = n Af <— M f <- (x,y) 
Q <- x = n + 1 A<- Ml 

The rule's hypotheses become 

(n G Nat A x = n) A [M\ x , y ) ((n G Nat A x' = n) V (x' = n + 1)) 
(n G Nat A x = n) A {Ml)( Xjy ) => (x 1 = n + 1) 
(n G Nat A x = n) =>• Enabled (A^l)^^) 

which follow easily from the definitions of Ail and Ai in Figure 3. The 
rule's conclusion becomes 



$ A (n G Nat) => 0(x > n) 



(31) 



$ =>■ (( n G Nat A x = n) (x = n + 1)) 



(32) 



D [^](x,y) A WF^^A-ll) => ((n G Nat A x = n) (x = n + 1)) 



which, by definition of implies (32). 
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7.3 Other Properties 

We have seen how invariance properties and eventuality properties are ex- 
pressed as TLA formulas and proved. But, what about more complicated 
properties? How would one state the following property as a TLA formula? 

A behavior begins with x and y both zero, and repeatedly in- 
crements either x or y (in a single operation), choosing nonde- 
terministically between them, but choosing each infinitely many 
times. 

The answer, of course, it that we already have expressed this property in 
TLA. It is formula $ of Figure 3. 

In TLA, there is no distinction between a program and a property. In- 
stead of viewing f as a description of a program, we can just as well consider 
it to be a property that we want a program to satisfy. The formula like 
the program of Figure 1 that it represents, is so simple that we can regard 
it as a specification of how we want a program to behave. As our next ex- 
ample, we consider a program that implements property That is, we will 
give a program represented by a TLA formula $ that implies 

8 Another Example 
8.1 Program 2 

Our next example is Program 2 of Figure 6 on the next page, written in a 
language invented for this program. (Since its only purpose is to help us 
write the TLA formula, the programming-language description of the pro- 
gram can be written with any convenient notation.) The program consists of 
two processes, each repeatedly executing a loop that contains three atomic 
operations. The variable sera is an integer semaphore, and P and V are the 
standard semaphore operations [8]. Since Figure 6 is an informal descrip- 
tion, it doesn't matter whether or not you understand it. The real definition 
of Program 2 is the TLA formula $ defined below. 

Describing the execution of Program 2 as a sequence of states requires 
each state to specify not only the values of the variables x, y, and sera, but 
also the control state of each process. Control in process 1 can be at one 
of the three "control points" ai, /3i, or 71. We introduce the variable pc 1 
that will assume the values "a" , "b" , and "g" , denoting that control is at 
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var integer x, y = 0 ; 
semaphore sera = 1 ; 




endloop 



fh- {y.= y+l); 
7 2 : ( V(sera) ) 



endloop 



coend 



Figure 6: Program 2 — our second example program. 



ai, /3i, and 71, respectively. A similar variable pc 2 denotes the control state 
of process 2. 

The definition of the TLA formula $ that represents Program 2 is given 
in Figure 7 on the next page. 4 We have used the following convention to 
make our formulas easier to read: a list of formulas preceded by "A"s denotes 
the conjunction of those formulas. Thus, Figure 7 defines the predicate Initq, 
to be the conjunction of three formulas, the second of which is (x = 0) A (y = 



As we explained in Section 6.5 (page 18), a program is represented by a 
formula Init A n[AT]f A F. In this example, the formulas Init and / are fairly 
obvious: Init is the predicate Initq, that specifies the initial values of the 
variables, and / is the 5-tuple w consisting of all the program's variables. 
The next-state relation Af and the fairness condition F are less obvious and 
merit some discussion. 

8.1.1 The Next-State Relation 

Corresponding to the six atomic operations in Figure 6 are the six actions 
ai, . . . , 72 defined in Figure 7. The four conjuncts in the definition of et\ 
assert that an et\ step: 

1. Starts in a state with pc 1 = "a" (control in the first process is at 
control point a\) and 0 < sera (the semaphore is positive). 

2. Ends in a state with pc 1 = "b" (control in the first process is at control 
point /3i). 

4 Section 10.2 discusses why Figure 7 is longer and seems more complex than Figure 6. 



0). 
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Initq, = A (pc 1 = "a") A (pc 2 = 
A (x = 0) A \y = 0) 
A sera = 1 

ai = A (pc x = "a") A (0 < sera) 

A pc\ = b 

A sera' = sera — 1 

A Unchanged (x,y, pc 2 ) 

fli = A pc x = "b" 

A pc\ = g 

A a;' = x + 1 

A Unchanged (y, sera, pc 2 ) 

A „ „ 

7i = A pc x = g 

A / 11 JJ 

A pc^ = a 

A sera' = sera + 1 

A Unchanged (x,y, pc 2 ) 

Mi = aiVftV 7i 

AT = Mi V A^ 2 

w = (x,y, sera, pc-^, pc 2 ) 

* = Jm^ A □[AT] U , A SF u ,(ATl) 

Figure 7: The formula 



a ) 

a 2 = A (pc 2 = "a") A (0 < sera) 

A / "I " 

A pc 2 = b 

A sera' = sera — 1 

A Unchanged (x,y, pc x ) 

/3 2 = A pc 2 = "b" 

A pc' 2 = g 

A y' = y+l 

A Unchanged (x, sera, pc-^) 

7 2 = A pc' 2 = a 

A " " 

A pc 2 = g 
A sera' = sera + 1 
A Unchanged (s,y,pc 1 ) 
AT 2 = a 2 V /3 2 V 72 

'\ SF U ,(AT2) 

3> describing Program 2. 
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3. Decrements sem. 

4. Does not change the values of x, y, and pc 2 

Thus, an a\ step represents an execution of statement a\ of Figure 6. Sim- 
ilarly, the other actions represent the other operations of the program in 
Figure 6. 

An Mi step is either an cti step, a (3i step, or a 71 step, so it represents 
an execution of an atomic operation by the first process. Similarly, an M2 
step represents an execution of an atomic operation by the second process. 
An M step represents a step of either process, so every program step is an M 
step — in other words, M is the program's next-state relation. Thus, □[A / '] u , 
is true for a behavior iff every step of the behavior is either a program step 
or else leaves the variables x, y, sem, pc 1 , and pc 2 unchanged. 



8.1.2 The Fairness Condition 



We want program $ to implement program Hence, $ must guarantee 
that both x and y are incremented infinitely often. To guarantee that x is 
incremented infinitely often, we need some fairness condition to ensure that 
infinitely many Mi steps occur. This condition must rule out the following 
behavior, in which process 1 is never executed. 



A „ A „ A 1 A 

= 0, y = 0, sem = 1, pc x = 

A „ A „ A „ A 

= 0, y = 0, sem = 0, pc 1 = 

A „ A 1 A „ A 

= 0, y = 1, sem = 0, pc 1 = 

A „ A 1 A 1 A 

= 0, y = 1, sem = 1, pc 1 = 

a „ a 1 A „ A 

= 0, y = 1, sem = 0, pc x = 

A „ A 0 A „ A 

= 0, y = 2, sem = 0, pc 1 = 

A „ A n A 1 A 

= 0, y = 2, sem = 1, pc x = 



"a" 


A 

, PC 2 = 


"a" , . . . )) 


"a" 


A 

, PC 2 = 


"b" , . . . )) 


"a" 


A 

, pc 2 = 


"g"> •••)) 


"a" 


A 

, PC 2 = 


"a" , . . . )) 


"a" 


A 

, PC 2 = 


"b" , . . . )) 


"a" 


A 

, PC 2 = 


"g"> •••)) 


"a" 


A 

, PC 2 = 


"a" , . . . )) 



Observe that an ai step is possible iff pc 1 equals "a" and sem is positive, so 
Enabled ai equals (pc 1 = "a") A (0 < sem). In this behavior, Enabled ai is 
true whenever pc 2 equals "a" , and false otherwise — both situations occurring 
infinitely often. An ai step is also an Mi step. Moreover, every ai step 
changes pc 1 and sem, so it changes w. Hence, any ai step is an (A/i)^, step, 
so (Mi) w is enabled and disabled infinitely often in this behavior. 
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The weak fairness condition WF TO (A/i) asserts that (Afi) w is disabled 
infinitely often or infinitely many (Afi) w steps occur. Since (Afi) w is disabled 
infinitely often, WF TO (Ai) does not rule out this behavior. 

The strong fairness condition SF w (A/"i) asserts that either (Afi) w is even- 
tually forever disabled or else infinitely many (Afi) w steps occur. Neither 
assertion is true for this behavior, so the behavior does not satisfy SF w (A/"i). 
This example indicates why we need the fairness condition SF w (A/"i) to guar- 
antee that x is incremented infinitely often. 

There are other ways of writing this fairness condition. An equivalent 
definition of $ is obtained by replacing SF u ,(A / i) with SF w (ai) A $Y w (fii) A 
SF w (7i) or with SF w (ai) A WF w (/?i) A WF w (7i). Equivalence of these def- 
initions follows from the formulas 



Inity A □ [AT] w SF W (A/"i ) 

Initq, A a[Af] w SF u ,(/3i) 
Inity A a[Af] w SF tu (7i) 



= ASF^(ai) (33) 

A SF u ,( 7l ) 

= WF U ,(/3 1 ) (34) 

= WF u ,( 7l ) (35) 



Intuitively, (33) holds because once control reaches ai, /3i, or 71, it remains 
there until the corresponding action is executed; (34) holds because once 
control reaches /3i, action (3i is enabled until it is executed; and (35) is 
similar to (34). 

Corresponding reasoning about y and Ni leads to the fairness condition 
SF u ,(A / 2) for the second process. 



8.2 Proving Program 2 Implements Program 1 

To show that Program 2 implements Program 1, we must prove the TLA 
formula $ =>■ where $ is defined in Figure 7 on page 32 and $ is defined in 
Figure 3 on page 18. By these definitions, $ =>■ $ follows from the following 
three formulas. 

Initij, =>■ Init$ (36) 
n[AT] w n[M\ x<y) (37) 
* WF M (M 1 )AWF M (M 2 ) (38) 

Formula (36) asserts that the initial condition of $ implies the initial 
condition of It follows easily from the definitions of Initq, and Initq,. 
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Roughly speaking, formula (37) asserts that every Af step simulates an 
Ai step, and (38) asserts that Program 2 implements Program l's fairness 
conditions. We now sketch the proofs of these two formulas. 

8.2.1 Proof of Step-Simulation 

Applying rule TLA2 of Figure 5 with true substituted for P and Q shows 
that (37) follows from 

W]w [M] {Xiy) (39) 

By definition, [Af] w equals et\ V . . . V 72 V (w ! = w) and [Al]^^) equals 
Ai\ V M2 V ((x, y)' = (x, y)). Formula (37) therefore follows from 

"i (x,y)'=(x,y) a 2 (x,y)'=(x,y) (40) 

fh => Mi fh => M 2 

71 (x,y)'=(x,y) 72 (x,y)'=(x,y) 

(w' = w) (x,y)' = (x,y) 

The reader can check that all these implications are trivial consequences of 
the definitions. 

8.2.2 Proof of Fairness 

For the fairness condition (38), we sketch the proof that $ implies 
W~F( Xt y}(Aii). The proof that it implies WF^^A^) is similar. 

Strong fairness of Program 2 is necessary to insure that x is incremented 
infinitely often, so Figure 5 suggests applying SF2 (without the overbars). At 
first glance, SF2 doesn't seem to work because its conclusion implies a strong 
fairness condition, and we want to prove $ =>■ WF^ , 2/ )(A / ii). However, if x 
is a natural number, so 1' / 1 + 1, then Enabled All equals true. A simple 
invariance argument proves $ =>■ 0(x £ Nat), so $ =>■ 0(Enabled All). 
Hence, $ implies that SF^ )2/ )(A / ii) and WF^ )2/ )(A / ii) are equivalent — both 
being equal to □0(A / ii)( :E)2/ ). It therefore suffices to prove $ =>■ SF^^Ali). 

Comparing the conclusion of rule SF2 with the formula we are trying to 
prove apparently leads to the following substitutions in the rule. 

A/ <- A/ M <- All / w g^(x,y) 

However, it turns out that we need to strengthen A/ by the use of an in- 
variant. We must find a predicate / (an invariant) that rules out these bad 
states and satisfies 

Inity A a[Af] w □/ (41) 
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By rule INV2, we can then rewrite $ as 

Inity A n[AfMM'] w A SF^(M) A SF^A^) 

and substitute Af A / A F for Af. We will discover the invariant / in the 
course of the proof. 

The first hypothesis of the rule and (40) suggest substituting fi\ for 
B. The conclusion and the second hypothesis leads to the substitution of 
Af\ for A and SF^A/^) for OF, using the temporal tautology SF^A/^) = 
□ SF W (A2). The second and fourth hypotheses lead to the substitution of 
pc 1 = "b" for P. With these substitutions, the proof rule becomes 

{ArMM , A(3 1 ) w (A^i) ( ^) 

(p Cl = "b" ) A (pc[ = "b" ) A (Af A I A F A A/i } w fh 
(pc 1 = "b") A Enabled {A4i)( x ,y) =^ Enabled (Af\) w 
u[N M M' A-./3i] u ,ASF4A/i)ASF4A/" 2 ) Oa(p Cl = "b") 
D[ATMAF] W ASF u ,(iV 1 ) ASF U ,(A^ 2 ) ^ SF ( ^)(A^i) 

The first three hypotheses are simple action formulas. The second and 
third follow easily from the definitions of A/"i, /3i and A^i. To prove the 
first hypothesis, we must show that Af A / A F A fi\ A (u/ 7^ w) implies 
Ai\ A ((x,y)' (x,y)). As we observed in (40), (3\ implies Ai\. Since /3i 
also implies x' = x + 1, which implies a;' 7^ a; if a; is a natural number, the 
first hypothesis holds if the invariant / implies x £ Nat. 

The fourth hypothesis is a temporal formula, which we now examine. To 
simplify the intuitive reasoning, let us ignore steps that don't change w. The 
fourth hypothesis then asserts that if every step is an Af A I A I' step that 
is not a (3i step, and the fairness conditions hold, then eventually control 
reaches (3i and remains there forever. From the informal description of the 
program in Figure 6, this seems valid. No matter where control starts in 
process 1, fairness implies that eventually it must reach /3i, where it must 
remain forever if no (3i step is performed. 

Unfortunately, this intuitive reasoning is wrong. The fourth hypothesis 
is not a valid TLA formula. For example, consider a behavior that starts 
in a state with pc 1 = pc 2 = "a" and sem = 0, and that remains in this 
state forever. In such a behavior, the left-side of the implication in the 
fourth hypothesis is true, but pc 1 never becomes equal to "b". Thus, the 
hypothesis is not satisfied by these behaviors. 

The fourth hypothesis is invalid for behaviors starting in "bad" states — 
ones that are not reachable by executing the program from an initial state 
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satisfying Initq,. Such states have to be ruled out by the invariant /. We 
must substitute SF W (M 2 ) A □/ for F and (pc x = "b") A I for P in Rule SF2, 
obtaining the following as the fourth hypothesis. 

G Oa((p Cl = "b") A I) (42) 

where G = 0[J\f A I A I' A -^fi\] w A SF tu (AT 1 ) A SF U ,(AT 2 ) A □ / 

Remembering that / must imply x £ Nat, the reader with experience reason- 
ing about concurrent programs will discover that the appropriate invariant 
is 

/ = A a; £ Nat 

A V (sera = 1) A (pc 1 = pc 2 = "a") 

V (sera = 0) A V (pc x = "a") A (pc 2 £ {"b", "g"}) 
V (pc 2 ="a") A(p Cl £{"b","g"}) 

(Note the use of "V" lists to denote disjunctions, and of indentation to 
eliminate parentheses.) With this definition of /, the invariance property 
(41) follows easily from Rule INV1. 

Having deduced that we need to prove (42), we must understand why it 
is true. A little thought reveals that (42) holds because control in process 1 
must eventually reach /3i, and □[A/'. . .A^(3i] w , which asserts that a (3i action 
is never executed, implies that control must then remain there forever. This 
reasoning is formalized by applying simple temporal reasoning based on the 



Lattice Rule to derive (42) from: 

G ( (pc, = "g" ) A / ^ (p Cl = "a" ) A I) (43) 

G ( (pcj = "a" ) A / (p Cl = "b" ) A I) (44) 

G ( (p c i = "b") A i" =>■ □((pc 1 = "b") A I) ) (45) 



To see how to prove these formulas, we once again use simple pattern- 
matching against the proof rules of Figure 5. We find that (43) and (44) 
should be proved by Rule SF1 with AT\ substituted for A and SF u ,(A / 2) 
substituted for OF, and that (45) should be proved by rule INV1 with 
(pc 1 = "b") A / substituted for /. The proofs of (43) and (45) are simple. 
The proof of (44) is not so easy, the hard part being the proof of the third 
hypothesis: 

H => O Enabled (M)™ (46) 
where H = A □((pc 1 = "a") A /) 

A □[A^A/A/ / A^/3i] u , 
A SF U ,(AT 2 ) 
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Once again, we have reached a point where blind application of rules fails; 
we must understand why (46) is true. If pc 1 equals "a", then action AT\ is 
enabled when control in process 2 is at and strong fairness for Ni implies 
that control must eventually reach a 2 . This intuitive reasoning leads us to 
deduce (46) by temporal reasoning from 

(pc 1 = "a") A / =>■ (Enabled (Afi) w = (pc 2 = "a")) 

H =>• ((P C 2 = " b ") ^ (P C 2 = "g")) 
H =>• ((P C 2 = "g") ^ (P C 2 = " a ")) 

The first formula follows from the observation that 

Enabled (Af\) w = V pc 1 = "a" A 0 < sem 

V pc 1 = "b" 

V Fi= g 

Pattern-matching against the proof rules leads to simple proofs of the re- 
maining two formulas by substituting A^ for A and true for F in SF1. 

8.3 Comments on the Proof 

This example illustrates the general method of proving that a lower-level 
program $ implements a higher-level program There are three things to 
prove: (i) the initial predicate of $ implies the initial predicate of (ii) a 
step of $ simulates a step of and (iii) $ implies the fairness condition of 

As in the example, proving the initial condition is generally straightfor- 
ward. Of course, in more realistic examples there will be more details to 
check. 

Because our example was so simple, the proof of step-simulation was 
atypical. Usually, a step of the lower-level program starting in a completely 
arbitrary state does not simulate a step of the higher-level program. We 
must first find the proper invariant, and then apply Rule INV2 to prove 
step-simulation. Once the invariant is found, the proof is a straightforward 
exercise in showing that one action implies another. The structure of the 
formulas tells us how to decompose a large proof into a number of smaller 
ones. 

Our proof of fairness was quite typical in its alternation of blind appli- 
cation of proof rules with the need to understand why a property holds. As 
in this proof, an invariant is almost always required. Usually, it is the same 
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invariant as in the proof of step-simulation. Of course, the proofs of real 
algorithms will be more complicated. 

Our proof may already have seemed rather complicated for such a simple 
example, but the example is a bit more subtle than it appears. The reader 
who attempts a rigorous informal proof will discover that each step in the 
TLA proof mirrors a step in the informal proof. The more rigorous the 
informal proof, the more it will resemble the TLA proof. Rules SF1 and 
SF2 conveniently encapsulate reasoning that occurs over and over again in 
informal proofs. We believe that temporal logic provides an ideal formalism 
for translating intuitive understanding of why a liveness property holds into 
a formal proof. 

Were we to choose the weaker fairness requirement WF^^^AI) for Pro- 
gram 1 , then Program 2's fairness condition could be weakened to WF U ,(A / '). 
The proof of $ =^ using WF2 instead of SF2, would then be simpler. 
Writing out this proof is a good exercise in applying TLA. 

8.4 Stuttering and Refinement 

Observe that Program 2 is finer-grained than Program 1, in the sense that 
the three atomic operations of each process's loop in Program 2 correspond 
to a single atomic operation of Program 1. Besides the steps that increment 
x or y, Program 2 takes steps that modify sera and pc 1 or pc 2 , but leave x 
and y unchanged. Program 2 implements Program 1 — that is, the formula 
$ =^ $ is valid — only because $ allows "stuttering" steps that do not change 
x and y. Program 2 can in turn be implemented by a still finer-grained 
program because $ allows steps that do not change any of its variables. 

Allowing stuttering steps is the key to refining the grain of atomicity. 
We abandoned the simple RTLA formula $ of Figure 2 on page 14 because 
it did not allow stuttering steps. 

A temporal formula F is said to be invariant under stuttering iff (j{Fj 
and t[_F] are equivalent whenever a and r differ only by stuttering steps. To 
formalize this definition, we first define \a to be the behavior obtained from 
the behavior a by removing all stuttering steps — except that if a ends with 
infinite stuttering, then those final stuttering steps are kept. The precise 
definition is: 

l]((so,si,S2, • • •)) = if Vn G Nat : s n = s 0 (47) 

then ((s 0 ,s 0 ,s 0 , . . .)) 
else if si = s 0 then \\{{s 1 ,s 2 ,s 3 , . . .)) 

else ((s 0 )) o []((si,S2,. . .)) 
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where o denotes concatenation of sequences. A temporal formula F is in- 
variant under stuttering iff \a = \t implies o\F\ = t[_F], for all behaviors 
a and r. Every TLA formula is invariant under stuttering, but not every 
RTLA formula is. 

9 Hiding Variables 

9.1 A Memory Specification 

We now consider another example: a simple processor /memory interface. 
The processor issues read and write operations that are executed by the 
memory. The interface consists of three registers, represented by the follow- 
ing three variables. 

op: Set by the processor to indicate the desired operation, and reset by the 
memory after executing the operation. 

adr: Set by the processor to indicate the address of the memory location to 
be read or written. 

val: Set by the processor to indicate the value to be written by a write, and 
set by the memory to return the result of a read. 

Here is a typical behavior, where " — " indicates that the value is irrelevant, 
and memory location 432 happens to have the initial value 777. 

((op = "ready" , adr = — , val = — , . . . )) 
((op = "read", adr = 432, val = — , . . . )) 
((op = "ready", adr = — , val = 777, . . . )) 
((op = "write", adr = 196, val = 0, • • • )) 
((op = "ready" , adr = — , val = — , . . . )) 

It is easy to specify this interface if we introduce an additional variable mem- 
ory to denote the contents of memory, so memory(n) is the current value 
of memory location n. The property $ describing the desired behaviors is 
shown in Figure 8, where Address is the set of legal addresses, and MemVal 
is the set of possible memory values. Action S(m,v) represents the assign- 
Note 13 ment memory(m) := v. Actions lZ proc and W vroc represent the processor's 
read- and write-request operations; actions lZ mem and W mem represent the 
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Initq, 
S(m, v) 

/\"proc 



proc 



M 

w 



mem 
A 



A op = "ready" 

A Vn G Address : memory (n) G MemVal 

= Vn G Address : A (n = m) 
A (n/m) 



= A op = "ready" TZ m 

A op = read 

A adr' G Address 

A memory' = memory 

= A op = "ready" W„ 

A op' = "write" 

A adr' G Address 

A val' G MemVal 

A memory' = memory 

— V V W 

— /v mem v ' v mem 

N mem V ^'proc V ~^proc 

(op, adr, val, memory) 

Initq, A a[Af] w A WF w (Af mem ) 



memory [n ) = v) 
memory (n)' = memory (n)) 

= A op = read 
A op' = "ready" 

A val' = memory (adr) 
A memory' = memory 
l = A op = "write" 
A op' = "ready" 
A S(adr, val) 



Figure 8: "Internal" specification of a processor /memory interface. 



memory's responses to those requests. Action N mem denotes the memory's 
next-state relation. The fairness condition WF w (N' mem ) asserts that the 
memory eventually responds to each request; there is no requirement that 
the processor ever issues requests. 

Observe that the action S(m,v) is used only to define W mem ; it was 
introduced just to keep the definition of W mem from running off the page. 
There is no formal significance to our choice of names such as lZ proc . Our 
decision to define N mem as the disjunction of two simpler actions was com- 
pletely arbitrary; we could just as well have defined it all at once, or as the 
disjunction of more than two actions. There are countless ways of writing 
logically equivalent formulas 

The formula $ specifies the right behavior for the interface variables op, 
adr, and val. However, it also specifies the value of the variable memory, 
which we did not want to specify. We want to specify only how the three 
interface variables change; we do not care how any other variables such as 
x, sem, or memory change. We therefore want a formula asserting that op, 
adr, and val behave as described by but that it doesn't matter what 
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values memory assumes. Such a formula is sometimes described as $ with 
the variable memory "hidden". This formula is written 3 memory : 

The precise meaning of the formula 3 memory : $ is defined below. 
Here, we simply want to observe that the free (program) variables of this 
formula are op, adr, and vol. Since x, sem, and memory do not occur free, 
the formula does not constrain them in any way. 

9.2 Quantification over Program Variables 

We now define 3 x : F, where a; is a (program) variable and F a temporal 
formula. Intuitively, 3 x : F asserts that it doesn't matter what the actual 
values of x are, but that there are some values x can assume for which F 
holds. For example, 3 x : 0[y = x']^ x ^ is satisfied by the behavior 

// A „ „ A „ A ss 

\x = a , y = 0, z = true, ...)) 

(x = "b", y = 1, z = -13, . . .)) 

x = c, y = 1, z = -13, . . .)) 

(x = 77, y = 2, z = true, . . . )) 

because by changing only the values of x, we get the following behavior that 
satisfies 0[y = x']^ x ^ y y 

\x = a , y = 0, z = true, ... J 

(x = 0, y = 1, z = -13, . . .)) 

(a; = 1, y = 1, z = -13, . . .)) 

((a; = 1, y = 2, z = true, . . . )) 

In fact, every behavior satisfies 3 x : 0[y = x']^ x ^ y y 

To define 3 x : _F formally, we need some auxiliary definitions. For any 
variable x and states s and /, let s = x t mean that s and / assign the same 
values to all variables other than x. More precisely, 

s= x t = VV^V: S H = *H 

We extend the relation = x to behaviors in the obvious way: 

((s 0 ,s 1 , . . .)) = x {(* 0 , • • •» = V n G Nat : s n = x t n 
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The obvious next step is to define 

a{3x:F] = 3 r £ St°° : (a = x r) A r{F] 



(48) 



for any behavior a. (Recall that St°° is the set of all behaviors.) However, 
this definition is not quite right, because the formula it defines is not neces- 
sarily invariant under stuttering. For example, suppose F is satisfied only 
by behaviors in which x changes before y does, including the behavior 

// A -i A „ „ A v. 

| a; = 1, y = a , z = true, . . .)) 

// A 0 A „ „ A ss 

l[x = 2, y = a , z = true, . . .)) 
{x = 2, y = "b", z = true, . . .)) 

Then definition (48) implies that the behavior 

(x = 999, y = "a", z = true, . . .)) 
(x = 999, y = "a", z = true, . . .)) 
(x = 999, y = "b", z = true, . . .)) 

satisfies 3 x : F (because we can produce a behavior satisfying F by changing 
only the values of x). However, the behavior 

(x = 999, y = "a", z = true, . . .)) 
(x = 999, y = "b", z = true, . . .)) 

does not satisfy 3 x : F (because of the assumption that F requires x to 
change before y does). With appropriate values for all other variables, these 
two behaviors differ only by stuttering steps. Hence, with definition (48), 
3 x : F is not necessarily invariant under stuttering even though F is. 

To obtain invariance under stuttering, we must define 3 x : F to be 
satisfied by a behavior a iff we can obtain a behavior that satisfies F by 
first adding stuttering and then changing the values of x. The appropriate 
definition is 

a{3x:Fj = 3 p, r G St°° : (^ = \\p) A (p = x r) A t{F\ (49) 

The operator 3 x differs from ordinary existential quantification because 
it asserts the existence not of a single value to be substituted for x, but of 
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an infinite sequence of values. However, it really is existential quantification 
because it obeys the ordinary laws of existential quantification. In particular, 
the usual rules El and E2 of Figure 9 on the next page are sound. From these 
rules, one can deduce the expected properties of existential quantification, 
such as 

(3 x : F\/ G) = (3 x : F) V (3 x : G) 

We can extend TLA to allow quantification over rigid variables as well as 
program variables. Since the value of a rigid variable is constant throughout 
a behavior, quantification over rigid variables is much simpler than quantifi- 
Note 14 cation over program variables. However, it is of less use. The semantics of 
quantification over rigid variables is defined in Figure 9. 

General TLA formulas consist of all formulas obtained from simple TLA 
formulas by logical operators and quantification over program and rigid vari- 
ables. The syntax and semantics of quantification are summarized in Fig- 
ure 9 on the next page, which together with Figure 4 on page 21 gives the 
complete definition of TLA. 

9.3 Refinement Mappings 

9.3.1 Implementing The Memory Specification 

We now give a simple implementation of the processor /memory interface 
specified by the formula 3 memory : where $ is defined in Figure 8. The 
implementation uses a main memory and a cache, represented by variables 
main and cache. The value of cache (m) represents the cache's value for 
memory location m, the special value _L (assumed not to be in MemVal) 
denoting that this memory location is not in the cache. The processor's 
read and write requests are serviced from the cache, and separate internal 
actions (not visible from the interface) move values between the cache and 
main memory. When the processor reads a value not in the cache, the value 
is first moved into the cache and then put in val. 

The "internal" description, in which main and cache are free variables, 
is the formula $ of Figure 10 on page 46. The actions defined in the figure 
have the following interpretations. 

T(a, m, v) Represents the assignment a(m) := v. This action is introduced 
only to simplify the definitions of other actions. 

TZproi yV-pro The processor's read- and wnfe- request operations. 
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Syntax 

(general formula) = (formula) \ 3 (variable) : (general formula) 

| 3 (rigid variable) : (general formula) 
| (general formula) A (general formula) 
| ^(general formula) 



(formula) 



a simple TLA formula (see Figure 4) 



Semantics 
((s 0 ,s 1 , ...)) = 
^((s 0 ,s 1 ,s 2 , ■ ■ 



a{3 x : Fj 
a{3 c : F] 



A 



«*„, *!,...» = VneNat:VV^V:s n H = *nH 
) = if Vn G Nat : s n = so 

then ((s 0 ,s 0 ,s 0 , . . .)) 

else if si = s 0 then \\{{s 1 ,s 2 ,s 3 , . . .)) 

else ((s 0 )) o []((si,S2,. . .)) 
3 p,r G St°° : (tltr = ^) A (p = x r) A r[F] 
3c G Val : 



Proof Rules 

El. \-F(f/x) 



: F 



Fl. h F(e/c) 3 c : F 



E2. F => G 

x does not occur free in G 

(3 x : F) G 
F2. F G 

c does not occur free in G 



[3c:F) 



G 



where a; is a (variable) 

f is a state function 

c is a (rigid variable) 

e is a constant expression 



F, G are (general formula)^ 
s, so, to, si, ti, ... are states 
a is a behavior 



Figure 9: Quantification in TLA. 
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Inity = A op = "ready" 

A Vn G Address : (mam(n) 6 MemVal) A (cache(n) 

T(a, m, v) = Vn £ Address : A (n = m) =>• (a'(n) = a) 

A (n/m)^> (a'(n) = a(n)) 



-L) 



pro 



w. 



pro 



A op = "ready" 

A op' = "read" 

A arfr' G Address 

A Unchanged (mam, cache) 

A op = "ready" 

A op' = "write" 

A air' £ Address 

A m/' £ MemVal 

A Unchanged (mam, cache) 



n 



cch 



cch 



A op = "read" 

A cache(adr) ^ _L 

A op' = "ready" 

A val' = cache(adr) 

A Unchanged (mam, cache) 

A op = "write" 

A op' = "ready" 

A T (cache, adr, val) 

A Unchanged mam 



Cget(m) 



A cache (m) = _L 

A T (cache, m, mam(m)) 

A Unchanged (op, adr, 

val, mam) 



Cfl(m) 



V 
T 

u 



A cache(m) ^ _L 
A V op / "read" 

V m ^ arfr 
A T(mam, m, cache(m)) 
A T (cache, m, _L) 
A Unchanged (op, adr, val) 

H V ro V W pro V 7?. ccft V W cc ft V (3 m £ Address : C get (m) VCjj(m)) 

7?-ccft V W cc ft V (Cg e t(adr) A (op = "read")) 

(op, adr, val, mam, cache) 

Initis A n[V] u A WF U (T) 



Figure 10: A simple cached memory. 
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T^-cchi Week The memory's responses to processor requests, the value being 
read from or written to the cache. An 1Z cc h action can be executed 
only if the value to be read is in the cache. 

Cget(m), Cfl(m) The internal actions of moving a value from main memory 
to the cache, and of flushing a value from the cache to main memory. 
The second conjunct of Cfl(m) prevents a value from being flushed 
while it is being read. This is the only constraint on when values can 
be moved into or out of the cache; no particular cache maintenance 
policy is specified. 

V The next-state relation, which is the disjunction of all possible actions of 
the processor and the memory. 

T The disjunction of all the memory actions that must be performed to re- 
spond to a processor request. The third disjunct represents the action 
of moving the value for a read request from main memory into the 
cache. (It is enabled only if the value is not already in the cache.) 

If we consider main and cache to be internal variables, then the cached 
memory is described by the TLA formula 5 3 main, cache : The asser- 
tion that the cached memory correctly implements the processor /memory 
interface is expressed by the formula 

(3 main, cache : =^ (3 memory : $) (50) 

To prove (50), we define the state function memory by 

memory(m) = if cache(m) = _L then main(m) 

else cache(m) 

and then prove $ =^ where $ denotes the formula ^(memory / memory) 
obtained by substituting memory for all free occurrences of memory in 
Applying rule El of Figure 9, substituting memory for / and memory for 
x, we obtain $ =^ 3 memory : Rule E2 then yields (50). 

The formula $ =^ $ asserts that any sequence of values for the variables 
op, adr, and val, and for the state function memory, that is allowed by 
$ is a sequence of values that $ allows for the variables op, adr, val, and 
memory. We can regard memory as the "concrete" state function with 
which $ implements the "abstract" variable memory. 

5 As usual in logic, we write 3 x, y : F as an abbreviation for 3 x : 3 y : F, which by El 
and E2 of Figure 9 is equivalent to 3 y : 3 x : F. 
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How do we prove that $ implies $? To find the answer, we exam- 
ine the structure of For any formula F, let F denote the formula 
F( memory / memory) obtained by substituting memory for all free occur- 
rences of memory in F. For example, Jv is the state function (op, adr, val, 
memory). Then $ equals Initq, A n[J\T\ w A WF w (AT mem ). The formula $ 
therefore looks much like an ordinary TLA formula representing a program, 
with initial condition Initq, and next-state relation Af . The only difference 
is that instead of an ordinary weak fairness condition, $ has as a conjunct 
the "barred" fairness condition WF w (AT mem ). 

The proof of $ =>■ $ is similar to the proof in Section 8.2 that Program 2 
implements Program 1. We first prove that Initq, implies Initq,. We next 
prove that $ implies □[A / ']^ (step-simulation) by applying rule TLA2 of 
Figure 5 (page 22) with the substitutions 

A <-V B <-N f <- u g <-w P <- true Q <- true 

Finally, we prove that $ implies WF w (Af mem ) (fairness) by applying WF2 
with the substitutions 

M <— AT A^T / <- u 

M ±- V B^ U cch V W cch g^w 
P <— (op = "write") V (op = "read" A cache(adr) ^ _l_) 

(Observe that Rule WF2 has the appropriate "bars" to prove the desired 
conclusion.) As in our previous example, the proofs consist of straightfor- 
ward calculations punctuated by the occasional need for insight into why 
what we are trying to prove is true. 

This cached memory is quite abstract; it allows any policy for deciding 
when to move values between the cache and main memory. Given a particu- 
lar caching algorithm, we would prove that it implements the simple cached 
memory — meaning that the TLA formula representing the algorithm implies 
3 main, cache : By the transitivity of implication, this proves that the 
algorithm implements the memory /processor interface. 

9.3.2 Refinement Mappings 

It is clear how to generalize the example above to the problem of proving 
(3 x 1 ,...,x m : tf) (3 y 1 ,...,y n : $) (51) 

for arbitrary $ and We must define state functions yi, . . . , Ifa m terms of 
the variables that occur in $ and prove $ =>■ where $ denotes the formula 
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2/1 / 2/1 5 • • ■jUn/yn) obtained by substituting yl for the free occurrences of 
yi in for all i. We then infer (51) from rules El and E2. 

The collection of state functions ~y~\ , . . . , y^ is called a refinement map- 
ping. The "barred variable" is the state function with which $ implements 
the variable yi of 

To prove (51), one must find a refinement mapping such that $ =^ $ 
is valid. The completeness theorem then implies that the proof of $ =^ $ 
can be reduced to the proof of valid action formulas by using the rules of 
Figure 5. But can the requisite refinement mapping always be found? Does 
the validity of (51) imply the existence of a refinement mapping such that 
$ =^ <j> i s valid? 

The answer is no; a refinement mapping need not exist. As an example, 
we return to Programs 1 and 2, represented by formulas $ of Figure 3 on 
page 18 and $ of Figure 7 on page 32. Program 2 permits precisely the same 
sequences of values for x and y as does Program 1. Therefore, the formula 
3 sera, pci, pc 2 ■ which describes only the sequences of values for x and y 
allowed by Program 2, is equivalent to Can we prove this equivalence? 

We already sketched the proof of $ =^ which by Rule E2 implies 
(3 sera, pc 1 , pc 2 In this case, $ has no internal variables, so the 

refinement mapping is the trivial one consisting of the empty set of barred 
variables. Now consider the converse, 

$ =>• (3 sem,pc 1 ,pc 2 : $) (52) 

Can we define the requisite state functions sera, pc 1 , and pc 2 in terms of 
x and y (the only variables that occur in $) so that Program 1 allows 
them to assume only those sequences of values that Program 2 allows the 
corresponding variables to assume? Clearly not. There is no way to infer 
from the values of x and y what the values of sera, pc 1 , and pc 2 should be. 
Thus, there does not exist a refinement mapping for which $ implies 

To prove (52), one must modify $ by adding dummy variables. Intu- 
itively, a dummy variable is one that is added to a program without affecting 
the program's behavior. Formally, adding a dummy variable d to a formula 
II means finding a formula H d such that 3 d : H d is equivalent to II. (The 
variable d is assumed not to occur free in II.) Formula (52) can be proved 
by adding two dummy variables h and p to That is, we can construct a 
formula $> hp such that 3 h,p : $> hp is equivalent to and can then prove 

(3h,p:$ hp ) =>• (3 sem,pc 1 ,pc 2 : $) 
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by constructing a refinement mapping such that $ p implies The refine- 
ment mapping can be found because the state functions sera, pcTj", and pc^ 
are allowed to depend upon h and p as well as x and y. 

In general, refinement mappings can always be found if we add the right 
dummy variables. The completeness theorem of [1] shows that, under certain 
reasonable assumptions about $ and if (51) is valid, then it can in prin- 
ciple be proved by adding dummy variables to $ and finding the requisite 
refinement mapping. This theorem and the completeness theorem provide 
a relative completeness result for TLA formulas of the form (51) when $ 
and $ are formulas of the form Init A E\[AT\f A F, with F the conjunction of 
fairness conditions. 



9.3.3 "Barring" Fairness 

When $ has the canonical form Init A E\[AT\f A F, the formula $ equals 
Init A 0[Af]j A F. If F is the conjunction of fairness conditions of the 
form WFg(A4) and SF g (A4), then F is the conjunction of "barred" fairness 
conditions WF g (M) and SF g (M). 



We might expect that WF g (A4) would be equivalent to WFj(A4) and 
SF g (A4) equivalent to SF-g(Ai), but that need not be the case. It is true 
that 



WF g (M) = nO^Enabled {M) g V nO(M)j (53) 
SF g (M) = DO^Enabled {M) g V Oa(M)j 



However, Enabled {M) g is not necessarily equivalent to Enabled For 
example, let Ai be the action (x 1 = x) A (y' y), let g equal (x,y), and let 
the refinement mapping be defined by x = z and y = z. Then Enabled (Ai) g 
equals true, so Enabled (Ai) g equals true. But 

Enabled (M)j 



Enabled ((x' = x) A (y 1 ^ y))j^y) definition °f and d} 

Enabled ((af' = x) A (l/ 1 T/))(x,J) {by definition of 777} 

Enabled ((z' = z) A (z ! z))^ z ^ {by definition oix and y} 

Enabled false {by definition of ( . . .)...} 

false {by definition of Enabled } 



Thus, Enabled (Ai) g is not equivalent to Enabled In general, the 

primed variables in the action (Ai) g are not free variables of the expression 
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Enabled {Ai) g , so we can't obtain Enabled (Ai) g from Enabled (Ai) g by 
blindly barring all variables. 

In rules WF2 and SF2, the formulas WFgjM) and SF g (M) are defined 
by (53). The rules are sound when Ai is any action, g any state function, 
and Enabled (Ai) g any predicate — assuming that WY g (Ai) and SY g (Ai) 
are defined by (53). In practice, the barred formulas will be obtained from 
unbarred ones by substituting "barred variables" (state functions) for vari- 
ables, as in our example. 

10 Further Comments 
10.1 Mechanical Verification 

Because it is a simple logic, TLA is ideally suited for mechanization. Urban 
Engberg and Peter Gr0nning have been working on the mechanical verifi- 
cation of TLA, using LP — an "off-the-shelf" verification system based on 
rewriting [11]. Although initial experiments showed that LP can be used 
directly, it was decided to write a preprocessor. In addition to allowing 
more readable specifications, the preprocessor allows separate LP proofs for 
action formulas and temporal formulas, using simpler encodings of the for- 
mulas than would be possible with a single proof. Since most reasoning 
in a TLA proof is about actions, a simple encoding of action formulas is 
important. 

The proof in Section 8.2, that the formula $ describing Program 2 im- 
plies the formula $ describing Program 1, has been checked with LP. Fig- 
ure 11 shows the definitions of $ and $ in the actual preprocessor input. 
(Declarations and preprocessor directives have been omitted.) Observe that 
these definitions are almost perfect transliterations of the ones in Figures 3 
and 7. The major differences are the use of "*" to represent tuples and "<<" 
instead of "<" — differences introduced because comma and "<" have other 
meanings. 

Following these definitions is the preprocessor directive 

Prove Temp Psi => Phi 

that creates an LP theorem whose proof implies the validity of the temporal 
formula $ =>■ (The directive Prove Act is used for action formulas.) 
The rest of the preprocessor input is a proof of this theorem, consisting of 
a sequence of Prove directives and LP commands to prove the correspond- 
ing assertions. The only part of the proof that was not checked by LP is 
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InitPhi == (x = 0) A (y = 0) 

Ml == (x' = x + 1) A (y' = y) 

M2 == (y' = y + 1) A (x' = x) 

M == Ml \/ M2 

v == (x * y) 

Phi == InitPhi A [][M]_v A WF(v,Ml) /\ WF(v,M2) 



InitPsi == /\ (pel = a) A (pc2 = a) 

A (x = o) A (y = o) 

A sem = 1 

alphal == A (pel = a) A (0 << sem) 

A pel' = b 

A sem' = sem - 1 

A Unchanged(x * y * pc2) 



gamma2 == A pc2 = g 
A pc2' = a 
A sem' = sem + 1 
A Unchanged(x * y * pel) 

11 == alphal \/ betal \/ gammal 

12 == alpha2 \/ beta2 \/ gamma2 
I == II \/ 12 

w == (x * y * pel * pc2 * sem) 

Psi == InitPsi A [][N]_w /\ SF(w,Il) /\ SF(w,I2) 



Figure 11: The representation of the formulas $ and $ of Figures 3 and 7 
for the mechanical verification of the theorem $ =>■ 
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the computation of the Enabled predicates. Although algorithmically sim- 
ple, these computations are awkward to do in LP. A future version of the 
preprocessor will compute Enabled predicates. 

The work on mechanically verifying TLA formulas with LP is prelim- 
inary. So far, only very simple examples have been attempted. The pre- 
processor is a prototype, representing about two man-months of effort. The 
goal of the project is to assess the feasibility of implementing a verification 
system that will be useful for real problems. 

10.2 TLA versus Programming Languages 

Let us compare Figure 6, the description of Program 2 in a conventional 
programming language, with Figure 7, its representation as a TLA formula. 
At first glance, the program looks simpler than the TLA formula. However, 
the program seems simple only because you are already familiar with its 
notation. To understand what the program means, you need to understand 
the meaning of the var declarations, the cobegin, loop, and ":=" 
constructs, and the P and V operations. In contrast, everything needed 
to understand the TLA formula appears in Figure 4. It is easy to make 
something seem simple by omitting the complicated definitions needed to 
understand it. 

One reason for the conventional program's apparent simplicity is that it 
does not specify liveness properties. Nothing in Figure 6 told us that the 
fairness condition for $ should be strong fairness (SF^A^i) A SF^A^)) 
rather than weak fairness (WF W (A4)). To allow either fairness condition, 
a programming language should provide different flavors of cobegin and 
semaphore operations. If the language provides only one kind of fairness, 
specifying a different fairness condition requires a complicated encoding with 
additional variables — if it is even possible. 

The TLA formula is longer than the conventional program. The formula 
can be made shorter by defining some notation. For example, letting P(sera) 
equal (0 < sem) A {sera' = sera — 1) and v : d — ► e denote (v = d) A (V = e), 
action et\ can be written as 

ai = P(sera) A (pc 1 : "a" — ► "b") A Unchanged (x,y,pc 2 ) 

There are just two basic reasons why a TLA formula is longer than 
the corresponding conventional program: (i) what remains unchanged is 
implicit in a program statement, but must be stated explicitly in an action 
definition; and (ii) how the control state changes is implicit in the program, 
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but is described explicitly in the formula. We now discuss these two sources 
of length. 

The explicit Unchanged clauses add only about 10% to the length of 
the definition of $ in Figure 7; in more realistic examples, they might add 
somewhat less. Still, why pay that price? An obvious way of simplifying the 
formulas is to let the omission of a variable from an action mean that the 
variable is left unchanged. Thus, x' = x + 1 would be equivalent to (x 1 = 
x + 1) A (y 1 = y). However, this "simplification" would in fact make TLA 
much more complicated. For example, it would mean that the obviously true 
formula y' = y' is not equivalent to true, since the formulas (x 1 = x-\-l)A(y' = 
y') and x' = x + 1 would not be equivalent — the first would allow y to 
change and the second would not. Like ordinary mathematics, TLA is simple 
because a formula constrains only the variables that it explicitly mentions. 
This is what makes x' = x + 1 so much simpler than x := x + 1. Writing 
Unchanged clauses is a small price to pay for the simplicity of ordinary 
mathematics. 

The control structures of ordinary programming languages provide a 
convenient method of specifying that operations are to be performed in a 
particular order. Specifying this in TLA requires the use of explicit control 
variables, which are a source of complexity. However, remember that we 
are interested in reasoning about abstract descriptions of algorithms, not C 
code. An abstract algorithm usually has few separate actions, so its control 
structure is simple; if control variables are needed, they usually add little 
complexity. 

In abstract algorithms, it is just as common to specify that actions can 
occur in any order as it is to specify that they occur in some particular order. 
Conventional languages make it is awkward to allow operations to occur in 
any order. Dijkstra's guarded commands provide a simple mechanism for 
allowing nondeterminism, but they are ill-suited to describing concurrent 
programs. For example, can the statement 

do ( b — ► skip) D ( ->b — ► skip) do 

terminate if some other process is concurrently changing the boolean variable 
bl We do not know if Dijkstra has ever answered this question, but we 
believe that there is no single answer that is right in all circumstances. 
We urge the reader to code the cache example of Figure 10 in his favorite 
programming language. The precise liveness condition will probably be very 
difficult or even impossible to express within the language. Even ignoring 
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the liveness condition, we expect that the TLA formula will be simpler than 
the program. 

Any language will be better than TLA at representing a program written 
especially for that language. Furthermore, a familiar notation, no matter 
how cumbersome, invariably seems simpler than an unfamiliar one. Our 
experience suggests that after one gets used to its notation, the TLA de- 
scription of a "randomly chosen" algorithm is likely to seem simpler than its 
representation in a conventional programming language, though it may be 
longer. (If brevity were synonymous with simplicity, APL would be easier 
to read than Pascal.) 

10.3 Reduction 

An algorithm must ultimately be translated into a computer program. One 
develops a program through a series of refinements, starting from a high- 
level algorithm and eventually reaching a low-level program. Just as we 
went from Program 1 to the finer-grained Program 2, and from the simple 
processor /memory interface to the more complicated cached memory, the 
entire process from specification to C code could in principle be carried out 
in TLA. "All" we would need is a precise semantics of C, which would allow 
the translation of any C program into a TLA formula. 

In practice, the refinement will be carried out in TLA until it becomes 
obvious how to hand-translate the TLA formula into a program in a real pro- 
gramming language — one with a compiler that produces satisfactory code. 
But what does it mean for the translation to be obvious? From the point 
of view of concurrency, the translation from the TLA formula to the pro- 
gram is obvious when any step of the next-state relation corresponds to an 
atomic operation of the program. In this sense, the translation from an 
action (sem' = sem + 1) A Unchanged (. . .) to an atomic V(sem) program 
statement is obvious. 

Real programming languages usually guarantee only an extremely fine 
grain of atomicity. When executing the statement x := x + 1, the read 
and write of x might each consist of several atomic operations. It would be 
impractical to describe such a fine-grained program with a TLA formula. 
Instead, one refines the TLA formula to the point where each step of the 
next-state relation either corresponds to an atomic program operation like 
V(sem), or else can be implemented with any grain of atomicity — for exam- 
ple, because it occurs inside an appropriate critical section. 

When can an atomic operation be implemented with any grain of atom- 
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icity? To answer this, we must first ask: when does a fine-grained program 
implement a coarser-grained one? There have been a number of partial 
answers to this question. Some lie in folk theorems — for example, that if 
shared variables are accessed only in critical sections, then an entire criti- 
cal section is equivalent to a single atomic operation. Other answers lie in 
precise results stating that certain classes of properties are satisfied by a 
fine-grained program if they are satisfied by a coarser-grained version [18]. 

The question of when a fine-grained program implements a coarser- 
grained one is answered in TLA by a "reduction" theorem. This theorem 
seems to include all prior answers as special cases — both the folk theorems 
and the precise results. The precise statement of the theorem is somewhat 
complicated, and will be given elsewhere. Here, we give only a rough de- 
scription of what it says. The theorem's conclusion is approximately 

$ => 3 w 1 ,. . .,w n : $ red (w 1 /v 1 ,. . .,w n /v n ) A OR (54) 

where 

$ is the simple TLA formula (with no hidden variables) describing the orig- 
inal program. 

& re d is the coarser-grained "reduced" version of the program. 
v\, . . . , v n are all the variables that occur in $ and § re i- 
R is a predicate containing the variables W{ and V{. 

Think of the Vi as "real" variables and the W{ as "pretend" variables. For- 
mula (54) asserts that there exist pretend variables such that the original 
program operating on the real variables implements the reduced program 
operating on the pretend variables, and the relation R always holds between 
the real and the pretend variables. 

In applying the reduction theorem to critical sections, the reduced for- 
mula § re i is obtained from the original formula $ by changing the next-state 
relation to turn an entire execution of a critical section into a single step. 
The relation R asserts that the real and the pretend variables are equal when 
no process is in its critical section. 

In practice, one reasons about the reduced formula § re i and checks that 
(54) implies the correctness of the fine-grained formula For example, in 
the critical-section application, if a property does not depend on the values 
assumed by variables while processes are in their critical sections, then $ 
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satisfies the property if § re i does. One must then verify that the formula 
$ representing the actual program satisfies the hypotheses of the Reduction 
Theorem, without actually writing For complicated languages like C, 
which lack a reasonable formal semantics, this verification must be informal. 
Whether formal verification is practical, with either a new language or a 
useful subset of an existing one, is a topic for research. 

10.4 What is TLA Good For? 

TLA, like any useful formal system, has a limited domain of applicability. A 
formalism that encompasses everything is good for nothing. We believe that 
TLA is useful for specifying and verifying safety and liveness properties of 
discrete systems. Intuitively, a safety property asserts that something bad 
does not happen, and a liveness property asserts that something good does 
eventually happen. 

We feel that the most significant limitation of TLA is that TLA proper- 
ties are true or false for an individual behavior. Thus, one cannot express 
statistical properties of sets of behaviors — for example, that the program 
has probability greater than .99 of terminating. The only way we know of 
verifying such properties is to construct a formal model of the system, use 
TLA to verify that the system correctly implements the model, and then 
apply other techniques such as Markov analysis to verify that the model has 
the desired property. 

The limited expressiveness of TLA is not always a disadvantage. As 
we have seen, TLA allows fine-grained implementations of coarser-grained 
specifications because it can express only properties that are invariant under 
stuttering. A formalism that distinguished between doing nothing and tak- 
ing a step that produces no change would seem to have a tenuous relation 
to reality. Another class of properties whose inexpressibility in TLA causes 
us no concern are possibility properties. We have never found it useful to 
be able to assert that it is possible for a system to produce the right answer. 
Some formalisms use possibility properties as a substitute for liveness; they 
cannot prove that the system eventually does produce the right answer, so 
they prove instead that it might. Since TLA can express liveness properties, 
it needs no such substitute. 

We are advocating TLA as a logic for reasoning about systems that ex- 
hibit concurrent activity. Yet, the semantics of TLA is based on sequences 
of states, with no concept of concurrent activity. The execution of a con- 
current algorithm is modeled as a nondeterministic interleaving of "events", 
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where an event is the state-change produced by executing a single atomic 
operation. Various formalisms for describing concurrent systems have been 
proposed in which an execution is modeled as a partially ordered set of 
events, concurrent activity being represented by unordered events. For rea- 
soning about safety and liveness properties, partial orderings are completely 
equivalent to interleavings. In an interleaving model, a partial ordering of 
events corresponds to the set of total orderings consistent with it. A system 
satisfies a safety or liveness property iff every possible execution does. As- 
serting in a partial-ordering model that the property holds for all possible 
partial orderings of events is equivalent to asserting in an interleaving model 
that it holds for all possible sequences of events. Thus, a partial ordering 
semantics is not needed for reasoning about safety and liveness. 

The basic assumption underlying TLA (and most formalisms in com- 
puter science) is that an execution can be represented by a discrete col- 
lection of atomic events. This is what distinguishes discrete systems from 
continuous ones. In a register-transfer model of a computer, moving a value 
into a register is represented as a discrete event, even though it is achieved 
by continuously changing voltages. 

TLA can be used to reason about a discrete system even if its events 
depend upon continuous physical values. A particularly important physi- 
cal value is time. Best- and worst-case time bounds on algorithms can be 
expressed as safety properties and proved with TLA. For example, the as- 
sertion that an algorithm always terminates within 15 seconds is a safety 
property, where time having advanced 15 seconds without the algorithm hav- 
ing terminated is the "something bad" that does not happen. A description 
of how TLA is used to reason about real time appears in [2]. 

11 Historical Note 

TLA is in the tradition of assertional methods for reasoning about pro- 
grams. These methods go back to Floyd [10], who first proved partial cor- 
rectness and termination of sequential programs. Hoare [13] recast partial 
correctness reasoning into a logical framework. The first practical asser- 
tional method for reasoning about concurrent programs was proposed by 
Ashcroft [5]. Ashcroft's work was followed by a number of variations on the 
same theme [9, 14, 15]; but the one that became popular is the Owicki/Gries 
method, developed by Susan Owicki in her thesis [19], which was supervised 
by David Gries. All these methods, though clothed in different notations, 
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proved safety properties by the use of an invariant; they would be described 
in TLA as applications of Rule IN VI. 

Temporal logic was first used to reason about concurrency by Pnueli [20]. 
It provided the first practical approach to proving more general liveness 
properties than simple termination. Pnueli introduced the simple temporal 
logic described in Section 4, with predicates as the only elementary formulas. 
Pnueli's logic was not expressive enough to describe all desired properties. 
It was followed by a plethora of proposals for more expressive logics, all 
obtained by introducing more powerful temporal operators. Pnueli was the 
first to describe a program by a temporal logic formula [21]. He, and al- 
most everyone else who followed him, represented programs by formulas 
that are not invariant under stuttering, so a finer-grained program could 
not implement a coarser-grained one. The observation that invariance un- 
der stuttering permits refinement first appeared in [17]. While many of 
the earlier logics were expressive enough in theory, we believe that TLA is 
the first logic to provide a practical method for expressing a program as a 
formula that is invariant under stuttering. 

The use of primed and unprimed variables (or their equivalent) for de- 
scribing "before" and "after" states of a program probably goes back to 
the early 1970s; we do not know where it first appeared. The idea of actu- 
ally specifying a program operation by a relation between primed and un- 
primed variables appears to have been introduced independently by us [16], 
Hehner [12], and Shankar and Lam [23]. These approaches all used the 
convention that variables not mentioned are not changed, so they had the 
inherent complexity epitomized by the observation that y' = y' is not equiv- 
alent to true. 

The key contribution of TLA is the generalization of Pnueli's simple logic 
by allowing actions as elementary formulas. This provides the needed ex- 
pressive power with minimal additional complexity. Another important fea- 
ture of TLA is the mathematical simplicity it achieves by eschewing variable 
declarations and types. While many systems for reasoning about programs 
have been called "logics" , not all of them share with TLA the property that 
if F and G are formulas in the logic, then ->F and F A G are also formulas 
in the logic. 
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Notes 



Note 1 (page 4) 

Although Val is infinite, from a mathematical point of view it can be "small", 
since it can be restricted to values constructible by simple rules from prim- 
itive values such as booleans and integers. In particular, Russell's paradox 
can be avoided. 

Note 2 (page 5) 

Formally, an operator like + is a value (an element of Val), and we regard 
m + n as syntactic sugar for +(m,n). We assume an evaluation function 
eval that maps tuples of values to values — for example, eval( + , 2, 3) equals 
5, since 2 + 3 = +(2,3) = 5. The mapping eval is assumed to be total, so 
eval( + , "abc",true) and eval(2, + , false) are values, though we have no idea 
what values. (See the discussion of types on pages 27-28.) A state func- 
tion is either a value, a variable, or an expression of the form f(fi, . . . , f n ) 
where f,fi,...,f n are state functions. We define s[/(/i, . . . , f n )J to equal 
ew/(s[/],s[/i], . ..,[/„]), for any state s. 

Note 3 (page 5) 

We assume a syntactic class of boolean expressions, so a predicate is a 
boolean expression built from variables and values. For any values c and d, 
we assume that c = d and c 6 d are booleans. This implies that e = / and 
e G / are boolean expressions, for any expressions e and /. One can also 
define a richer class of boolean expressions. For example, one can define 
c > d to have the expected meaning if c and d are both numbers, and to 
equal false otherwise. With this definition, x > y is a predicate if x and y 
are variables. 

Note 4 (page 7) 

When proving the validity of an action by ordinary reasoning, x and x' must 
be considered distinct variables. For example, (x = y) =>■ (x' = y r ), which 
one might deduce by naive substitution of equals for equals, is not valid. 
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Note 5 (page 12) 



Formally, we should distinguish actions from temporal formulas. Letting 
0(A) denote the temporal formula that we now write A, we should rewrite 
(10) as 

((s o ,s 1 ,s 2 ,...))l0(A)] = s 0 lA] Sl 

We would then notice that the temporal formula we now write A V B can 
denote either 0(A V B) or 0(A) V 0(B). However, these two formulas are 
equivalent, which is why we can get away with writing A instead of 0(A). 

Note 6 (page 13) 

Formula $ of Figure 2 asserts that every step of Program 1 increments either 
x or y, but not both. We could allow simultaneous incrementing of x and y 
by simply redefining Ai to equal Ai\ V Ai 2 V A4i2, where 

M 12 = (x' = x + l)A(y' = y+l) 

However, there is no reason to complicate $ in this way. In representing the 
execution of x := x + 1 by a single step, we are already modeling a complex 
operation as one event. Nothing would be gained by allowing the additional 
possibility of representing the executions of two separate statements as a 
single step. 

Note 7 (page 14) 

To write the state function (x,y), we must assume that any pair of values 
is a value. More generally, we assume that (ci, . . .,c n ) is a value, for any 
values ci , . . . , c n . 

Note 8 (page 16) 

We have told a white lie; .Mi is not equivalent to {Mi)( Xty y For example, 
suppose there is a value oo such that oo + 1 equals oo, and let s be a state 
in which x has the value oo. Then the pair s,s is an A4\ step, but not 
an (M-i)[ x ,y) step. However, it is true that definitions (15) and (17) are 
equivalent, because Initq, A ^[-M]^ X:y ) implies that the values of x and y are 
always natural numbers, and n + 1 ^ n is true for any natural number n. 
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Note 9 (page 18) 

Observe that Enabled (M-i)[ x ,y) ls n °t equivalent to true. For example, 
{■Mi)(x,y) 1S n °t enabled in a state in which x equals oo (see Note 8). How- 
ever, (M-i)[ x ,y) i s enabled in any state in which a; is a natural number, so 
Init® AO[J\A]( Xjy -) implies OEnabled (A4i)( Xjy y Hence, (17) and the definition 
of $ in Figure 3 are equivalent. 

Note 10 (page 19) 

Program 1 itself provides another example of parallel composition as con- 
junction. Rule STL5 of Figure 5 (page 22) and some simple logic shows that 
$ is equivalent to $1 A $2, where 

$ x 4 (x = 0) A A WF^A^) 

$ 2 4 ( y = 0) A a[M 2 ] y A WF y (M 2 ) 

Formulas $1 and $2 can be viewed as specifications of the two processes 
forming Program 1, so $ = <I>i A <&2 asserts that $ is the parallel composition 
of these two components. The TLA formula for a multiprocess program 
can be written in this way as the conjunction of formulas representing its 
individual processes whenever each variable is modified by only one process. 

Note 11 (page 20) 

The hypothesis of STL1 means that F is a propositional tautology or is 
derivable by the laws of propositional logic from provable formulas. 

Note 12 (page 28) 

We are assuming that c > d is a boolean, for any values c and d (see Note 3), 
since p =^> q is guaranteed to be a boolean only if p and q are booleans. It 
is actually not necessary for "abc" £ Nat to equal false. The formula equals 
true even if "abc" should happen to equal 135. By not assuming that strings 
and numbers are disjoint sets, we allow implementations in which strings 
and numbers share a common representation — for example, as strings of 
bits. We do, however, assume that "abc" does not equal "xyz". 

Note 13 (page 40) 

In the definition of S(m,v), the symbols m and v are parameters. The 
expression S(adr, val) denotes the formula obtained by substituting adr for 
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m and vol for v in this definition. 
Note 14 (page 44) 

Quantification over rigid variables can be defined in terms of quantification 
over program variables by 

3c: F = 3x : F(xjc) A nffalse]^ 

where c is a rigid variable and x is any program variable that does not occur 
in the temporal formula F. 
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